RTC‐Based Dual Axis Solar Tracker - shalan/CSCE4301-WiKi GitHub Wiki
| Name | GitHub |
|---|---|
| Ramy Shehata | GM-Sniper |
| Seif Elansary | MrSykoPath |
| Mohamed Mansour | Hamdy1337 |
Github Repo: https://github.com/GM-Sniper/RTC-Based-Solar-Tracking
1. The Proposal
Presentation
https://drive.google.com/file/d/1ktbMrGxbf7lhoRjvtdPGQyNpiwED8spa/view?usp=sharing
Abstract / Elevator Pitch:
The RTC-Based Dual-Axis Solar Tracker is a smart embedded system designed to continuously orient a solar panel toward the sun in both azimuth and elevation directions. Instead of keeping the panel fixed at one angle throughout the day, the system uses time and date information from an RTC module to estimate the sun’s position and adjust the panel accordingly. This improves solar alignment and increases the potential energy captured by the panel over time.
The project was proposed to address a common limitation of fixed solar panels: as the sun moves across the sky, the panel becomes less optimally aligned and solar energy capture decreases. While fixed and single-axis systems are simpler, a dual-axis system can provide better tracking accuracy by following both horizontal and vertical sun movement.
The system is intended as a practical embedded tracking prototype rather than a large-scale commercial solar platform. Its focus is on reliable RTC-based tracking, motorized panel positioning, and a clean RTOS-based architecture.
Project Objectives & Scope:
Minimum Viable Product (MVP)
- Read time and date from the GPS module.
- Compute target solar orientation in terms of azimuth and elevation.
- Control two positional servo motors (180 degrees) to move the panel along two axes.
- Support RTC-based open-loop solar tracking.
- Use an RTOS-based architecture to separate timing, control, actuation, and UI tasks.
- Demonstrate continuous panel motion according to calculated solar position.
- Add GPS support for automatic location setup.
Stretch Goals
- Display tracking status locally on an LCD.
- Add LDR-based correction for a hybrid tracking approach.
- Add logging of panel angle, tracking state, and time.
- Add wireless telemetry or monitoring support.
2. System Architecture
Main Components
STM32 Nucleuo-L432KC
DS3231 RTC Module
Servo Motor (SG90) — Elevation and Azimuth
Ublox Neo-7M GPS Module
Solar Panel (Non Functional Usage)
LCD (20x4) Screen (If it works)
Schematics & Wiring:
The hardware design is centered around the STM32 Nucleo-L432KC board, which controls the tracking system and generates the PWM signals for the servo motors. The 3D-printed structure provides the mechanical base for the dual-axis solar tracker, where one servo controls the horizontal axis and the other servo controls the vertical/elevation axis.
The design uses two positional SG90 180 degrees servo motors to move the solar panel mount. Each servo receives a PWM control signal from the STM32 Nucleo-L432KC. The servo power lines are connected to a suitable 5V supply, while the servo signal lines are connected to PWM-capable GPIO pins on the Nucleo board. The grounds of the STM32 board and the servo power supply must be connected together to ensure a common reference for the PWM signals.
The NEO-7M GPS module is connected to the STM32 Nucleo-L432KC through a UART interface. The GPS module provides the system with location data, including latitude and longitude, and can also provide accurate time data. These values are used by the solar position algorithm to calculate the required azimuth and elevation angles for the tracker.
The solar panel used in the prototype is mounted on the 3D-printed dual-axis mechanism. In this stage, the panel is used mainly to represent the physical load and demonstrate the tracking motion rather than to generate usable electrical power.
Lastly, the LCD screen was intended to display tracking details such as angle, time and position. However, due to some complications, the LCD screen got shorted and we are in the works for fixing it.
High Level Architectural Diagram
3. Hardware Design
Component Selection and Bill of Materials (BOM)
| Component | Part / Model | Quantity | Purpose in Project | Interface / Connection | Notes | Cost / Link |
|---|---|---|---|---|---|---|
| Microcontroller Board | STM32 Nucleo-L432KC | 1 | Main controller for the solar tracking system | UART, PWM GPIO, power/GND | Runs the solar position logic and controls the motors | 1100 EGP/ Datasheet |
| GPS Module | NEO-7M GPS Module | 1 | Provides latitude, longitude, and accurate time data | UART | Used as the location/time source for the solar position algorithm | 575EGP / Datasheet |
| Elevation and Azimuth Servo Motor | SG90 Servo Motor | 2 | Controls the vertical tilt/elevation and horizontal tilt/azimuth axis of the panel | PWM signal from STM32 | Used to tilt the panel up and down | Given By the Workshop / Datasheet |
| 3D-Printed Dual-Axis Mount | Custom 3D-Printed Model | 1 | Mechanical structure for holding and moving the panel | Mechanical assembly | Includes the base, gear structure, panel holder, and servo mounting areas | Custom printed |
| Solar Panel | Mini Solar Panel / Demo Panel | 1 | Represents the panel being tracked | Mechanical mounting only | Used mainly for demonstrating tracking movement | Given by the Workshop |
| Servo Power Supply | 5V External Supply | 1 | Powers the servo motors | 5V and GND to servos | Servo ground must be connected to STM32 ground | Given by the Workshop |
| Jumper Wires | Male/Female Jumper Wires | As needed | Connects STM32, GPS, servos, and power lines | GPIO, UART, power, GND | Used for prototyping and testing | Given by the Workshop |
| Breadboard / Prototype Wiring Area | Breadboard or Direct Jumper Setup | 1 | Supports temporary wiring during testing | N/A | N/A | Given by the Workshop |
3D-Printed Mechanical Schematic
Schematics & Wiring:
Power Budget:
The STM32 Nucleo-L432KC is powered from the laptop through USB. The two SG90 servo motors and the NEO-7M GPS module are powered from an external 5V supply. The STM32 does not power the servos or the GPS module; it only provides PWM signals to the servos and UART communication with the GPS. All grounds are connected together.
| Component | Quantity | Supply Source | Current Used |
|---|---|---|---|
| STM32 Nucleo-L432KC | 1 | Laptop USB | 300 mA max |
| SG90 Servo Motor — Azimuth | 1 | External 5V supply | 730 mA |
| SG90 Servo Motor — Elevation | 1 | External 5V supply | 730 mA |
| NEO-7M GPS Module | 1 | External 5V supply | 67 mA |
| LCD Screen | 0 | Not connected | 0 mA |
External 5V Supply Requirement
The external 5V supply powers both SG90 servo motors and the NEO-7M GPS module.
SG90 azimuth servo upper stall current = 730 mA
SG90 elevation servo upper stall current = 730 mA
NEO-7M GPS maximum supply current = 67 mA
Total external 5V current required: 730 mA + 730 mA + 67 mA = 1527 mA Therefore, the external 5V supply must provide at least 1.527 A. A standard 5V 2A supply satisfies this requirement.
Power Summary
| Supply Rail | Powered Components | Required Current |
|---|---|---|
| Laptop USB | STM32 Nucleo-L432KC | 300 mA max |
| External 5V supply | Two SG90 servos and NEO-7M GPS module | 1527 mA minimum |
Notes
- The STM32 does not power the servos.
- The STM32 does not power the GPS module.
- The STM32 only sends PWM control signals to the servos.
- The STM32 communicates with the GPS module through UART.
- STM32 GND, servo GND, and GPS GND must be connected together.
- The LCD is excluded because it was removed from the active design.
Sources for the powers
- STM32 Nucleo-32 User Manual UM1956: USB power through CN1 is 300 mA max.
- u-blox NEO-7 Datasheet: maximum supply current is 67 mA.
- SG90 Servo Specification: stall current is 650 ± 80 mA, so the upper value used is 730 mA.
4. Software Implementation
4.1 Software Architecture:
RTOS-Based Software Architecture
The software is structured using FreeRTOS to separate the main responsibilities of the solar tracker into independent tasks. The gpsTask reads and parses GPS data from the NEO-7M module through UART, extracting the current time, date, latitude, and longitude. This data is then passed to the solarTask, which uses the GPS time and location to calculate the required solar azimuth and elevation angles using the solar position algorithm.
Task Communication
The tasks communicate using RTOS queues instead of directly calling each other’s control logic. The GPS task provides updated GPS information, while the solar task converts this information into target angles for the tracker. These target angles are then sent to the servoTask, which is responsible for controlling the two SG90 servo motors.
Servo Control
The servoTask is the only task that updates the motor outputs. It receives the target azimuth and elevation values, applies software limits and calibration constraints, then converts the angles into PWM signals. TIM1 is used to generate the PWM outputs for both servos, with one channel controlling the azimuth axis and the other controlling the elevation axis.
Debug and Monitoring
A low-priority debug task is used for system monitoring, debugging output, and future testing support. This keeps debugging separate from the time-sensitive GPS, solar calculation, and servo control tasks.
Overall Flow
The overall flow is: GPS data is received, the solar position is calculated, target angles are generated, and the servo task moves the panel accordingly. This RTOS-based structure keeps the system modular, easier to debug, and safer because each task has a clear responsibility.
4.2 Flowcharts & State Machines:
4.3 Key Algorithms:
Solar Position Algorithm
The main tracking algorithm calculates the sun’s position using the current time, date, latitude, and longitude. The GPS module provides the real-time location and UTC time, which are then passed into the solar position calculation. The algorithm outputs two important values:
- Azimuth angle: the horizontal direction of the sun.
- Elevation angle: the vertical height of the sun above the horizon.
These two values represent where the panel should point. The azimuth value is used for the horizontal servo, while the elevation value is used for the vertical servo.
GPS-Based Time and Location Input
The NEO-7M GPS module provides the system with latitude, longitude, date, and UTC time through UART. The GPS task reads the NMEA sentences from the GPS module, parses the useful fields, and checks whether the GPS fix is valid.
If the GPS data is valid, the system uses the GPS latitude, longitude, and UTC time for the solar position calculation. If the GPS fix is not ready yet, the system can temporarily use hardcoded fallback coordinates until valid GPS data is available.
Solar Angle to Servo Target Mapping
The solar position algorithm gives real-world sun angles, but the SG90 servos only accept a position command through PWM. Because of this, the calculated solar azimuth and elevation angles must be converted into safe servo target angles.
The system applies calibration limits so that the servos do not move beyond the physical limits of the 3D-printed structure. This prevents the motors from pushing against the frame or stalling.
The general mapping idea is:
calculated solar angle → limited safe angle → servo PWM pulse width
For example, if the calculated elevation angle is too low or too high for the mechanism, it is clamped to the nearest safe value before being sent to the servo.
Servo PWM Control Algorithm
The SG90 servo is controlled using a PWM signal with a 20 ms period, which is equal to 50 Hz. The position of the servo depends on the width of the HIGH pulse inside each 20 ms cycle.
Typical SG90 control values:
1000 µs pulse → one side of rotation
1500 µs pulse → center position
2000 µs pulse → opposite side of rotation
In our STM32 configuration, TIM1 is used to generate the PWM signals for both servos. Since the timer clock is 32 MHz, the prescaler is set to 31:
32 MHz / (31 + 1) = 1 MHz
This means each timer count equals 1 microsecond. The auto-reload value is set to 19999, so the timer counts from 0 to 19999, giving 20,000 counts total:
20,000 counts × 1 µs = 20,000 µs = 20 ms
This creates the required 50 Hz PWM signal.
Angle to Pulse Width Conversion
To move the servo, the desired angle is converted into a PWM pulse width. The basic formula is:
pulse_us = min_pulse + angle × (max_pulse - min_pulse) / 180
Using the standard range:
min_pulse = 1000 µs
center_pulse = 1500 µs
max_pulse = 2000 µs
Examples:
0° → 1000 µs
90° → 1500 µs
180° → 2000 µs
However, the actual project uses calibrated safe limits instead of blindly using the full 0–180 degree range. This protects the 3D-printed mechanism and prevents the servos from hitting mechanical stops.
Control Method
The system uses open-loop position control. This means the panel position is calculated from time and location rather than using light sensors or feedback from the panel. Since the SG90 servos are positional servos, they internally hold the commanded angle based on the PWM signal.
No PID control is currently used. The movement is based on calculated solar position, servo calibration limits, and PWM angle commands.
4.4 Development Environment:
- PlatformIO —> build system / project manager (IDE extension for VS Code)
- GCC ARM Embedded (arm-none-eabi-gcc) —> cross-compiler toolchain
- STM32Cube HAL / framework-stm32cubel4 —> hardware abstraction layer (pulled automatically by PlatformIO)
- FreeRTOS / CMSIS-OS2 —> RTOS, included via the STM32Cube framework
- OpenOCD —> on-chip debugger / programmer (used by PlatformIO to flash via ST-Link)
- VS Code —> IDE
- TeraTerm —> serial monitor (UART2 debug output at 9600 baud)
5. Progress
Progress 1 — ESP32 Proof of Concept Completed
The first working prototype was completed using the ESP32 as an early proof of concept. In this version, we used the basic solar tracking workflow by hardcoding the latitude and longitude of The American University in Cairo (AUC), while keeping the time-based calculation accurate to the current system time. We mainly used an RTC module with the single axis of the 3D printed compartment seen above.
This stage focused on proving that the system could calculate a solar position target and produce motor movement based on that calculated value. The location values were fixed in software, but the time input was treated as the changing variable given from the RTC module so the calculated solar position could update as time changed.
Completed in this stage
- Implemented an initial ESP32-based prototype.
- Hardcoded AUC latitude and longitude.
- Used current time as the main changing input for the solar position calculation.
- Verified that the tracking logic could produce a changing target value.
- Tested motor movement as a proof of concept.
- Confirmed that the basic software structure could support solar-position-based tracking.
Notes
This stage was not intended to be the final hardware platform. It was mainly used to validate the idea quickly before moving to the required STM32 Nucleo implementation.
Progress 2 — Transition to STM32 Nucleo-L432KC
Based on the feedback from the first progress presentation, the final implementation will move away from the ESP32 and will instead use the STM32 Nucleo-L432KC board as the main controller. In addition, we will remove the RTC Module and implement it using the GPS Module Neo-7M only
The goal of this stage is to reproduce the same solar tracking logic that was tested on the ESP32, but now on the STM32 Nucleo-L432KC. The system will use two SG90 servo motors, one for the horizontal axis and one for the vertical axis. The latitude and longitude may still be hardcoded during this stage so that the team can focus on verifying the STM32 timer/PWM control, servo movement, and solar position calculation first.
Planned work in this stage
- Move the firmware from the ESP32 proof-of-concept environment to STM32 development.
- Use the STM32 Nucleo-L432KC as the main controller.
- Configure PWM outputs for two SG90 servo motors.
- Use one SG90 servo for horizontal movement.
- Use one SG90 servo for vertical movement.
- Re-implement the time-based solar position logic on the STM32.
- Keep latitude and longitude hardcoded temporarily.
- Verify that the STM32 can calculate the target solar position and drive both servos safely.
Notes
This stage focuses on matching the successful ESP32 proof of concept, but on the required STM32 platform.
Progress 3 — Full System Integration with NEO-7M GPS
The final integration stage added the NEO-7M GPS module so the system no longer depends on hardcoded latitude and longitude values. The GPS module provided location data, and the system used that location together with its accurate time information to calculate the solar position.
In the completed system, the STM32 Nucleo-L432KC act as the main controller, the two SG90 servo motors control the dual-axis panel mount, and the NEO-7M GPS module provide the location and time needed for automatic solar tracking.
Planned work in this stage
- Interface the NEO-7M GPS module with the STM32 Nucleo-L432KC.
- Parse GPS latitude and longitude values.
- Use GPS-provided location instead of hardcoded AUC coordinates.
- Provide the solar position algorithm with real location data.
- Use accurate time and date data for solar position calculation.
- Control both SG90 servos using the calculated azimuth and elevation targets.
- Test the complete dual-axis solar tracking behavior.
- Validate that the panel responds correctly to changes in calculated sun position.
Final system
- Main controller: STM32 Nucleo-L432KC
- Horizontal axis motor: SG90 servo
- Vertical axis motor: SG90 servo
- Location source: NEO-7M GPS module
- Solar tracking method: time/location-based solar position calculation
- Output: dual-axis movement of the solar panel toward the calculated sun position
- Output: Details on the LCD Screen (When it works)
6. Testing, Validation & Debugging
6.1 Unit Testing:
Each subsystem was tested separately before full integration.
STM32 Board
The STM32 Nucleo-L432KC project was generated using STM32CubeMX and built in Keil. The clock setup, TIM1 PWM configuration, USART1 configuration, and FreeRTOS setup were checked before adding the full tracking logic.
Servo Motors
The two SG90 servos were tested using TIM1 PWM. PA8 was used for TIM1 Channel 1 and PA9 was used for TIM1 Channel 2. Both servos were first centered using a 1500 µs pulse, then tested with small movements to avoid stressing the 3D-printed structure.
GPS Module
The NEO-7M GPS module was tested through USART1 at 9600 baud. The goal was to confirm that the STM32 could receive GPS NMEA data and extract useful values such as time, date, latitude, longitude, and fix status.
Solar Position Algorithm
The solar position algorithm was first tested using hardcoded time and location values. This verified that the algorithm could produce reasonable azimuth and elevation outputs before using live GPS data.
6.2 Integration Testing:
The full system was tested by connecting the GPS input, solar position calculation, and servo control together.
The expected flow is:
- GPS provides time and location data.
- STM32 parses the GPS data.
- The solar algorithm calculates azimuth and elevation.
- The angles are mapped to safe servo positions.
- The SG90 servos move the 3D-printed solar tracker.
During integration testing, servo movement is limited to a calibrated safe range to prevent the motors from hitting the mechanical limits.
6.3 Challenges & Solutions:
Gear Ratio Calibration
One of the main challenges was calibrating the 3D-printed gear mechanism. The gear ratio was not known at first, so multiple testing iterations were needed to understand how servo rotation translated into movement of the tracker.
After testing, the working ratio was found to be 2:1. This means that a 180° movement from the servo results in about 90° of movement in the tracker mechanism.
Gear Friction and Sticking
During testing, the 3D-printed gears sometimes got stuck while rotating. This affected the smoothness of the movement and could cause the servo to struggle.
To reduce friction, WD-40 was applied to the gear mechanism. This improved the movement temporarily, but some mechanical resistance still remained, so the gear alignment and printed parts still need careful handling during testing.
GPS Satellite Lock
Another challenge was getting the NEO-7M GPS module to read satellites reliably. Without an antenna, the module took more than 20 minutes to get a usable signal.
After adding an antenna, the GPS lock time improved significantly and was reduced to around 1 minute.
360-Degree Motor Limitation
The first motor setup used one 180° positional servo and one 360° motor. However, the 360° motor was difficult to use for accurate position control because it does not directly hold a commanded angle like a positional servo.
Using the 360° motor would require extra hardware such as limit switches or feedback sensors, which would make the code and calibration more complex. Because of this, the design was changed to use two 180° SG90 positional servos instead.
Keil Community Edition Code Size Limit
Another issue was the Keil Community Edition code size limit. The project code exceeded the 32 KB compilation limit, reaching around 40 KB.
To solve this, the project was moved to PlatformIO as the build and upload environment. This allowed the team to continue development without being blocked by the Keil size restriction.
7. Results & Demonstration
7.1 Final Prototype:
7.2 Video Demonstration:
https://github.com/user-attachments/assets/ece22c25-1522-4e1e-9219-6899ded5c858
https://github.com/user-attachments/assets/48466722-2bcf-4372-a588-85f837f1e10b
https://github.com/user-attachments/assets/03837698-5f50-4421-a3f8-8111eb3ac52b
8. Project Management
8.1 Division of Labor
Ramy Shehata
- Developed the STM32 firmware structure and main codebase
- Supported the integration of the STM32, GPS module, servo motors, and 3D-printed structure
- Implemented the solar position calculation logic using GPS time and location
- Prepared documentation updates, diagrams, and project wiki content
Seif ElAnsary
- Integrated the NEO-7M GPS module with the STM32 through UART
- Parsed GPS data for time, date, latitude, longitude, and fix status
- Connected the calculated azimuth and elevation values to the servo control logic
- Integrated the two SG90 servo motors with the 3D-printed dual-axis structure
- Calibrated the servo movement and tested the safe mechanical range
Mohamed Mansour
- Helped test the full system behavior after combining GPS, solar calculation, and servo movement
- Helped with demo preparation, validation, and presentation material
- Determined the gear ratio between the servo rotation and the tracker movement
- Tested the 5V external power setup for the servos and confirmed common-ground wiring
- Helped debug mechanical issues such as gear friction, sticking, and movement limits
Shared Responsibility
- All team members contributed to testing, debugging, system integration, documentation, and final presentation preparation.
8.2 Timeline:
The project timeline is organized around the official course milestones, but the actual development work is divided into four implementation weeks.
Week 1 — Initial Setup and Core Subsystems
April 19, 2026 – April 25, 2026
- finalize hardware selection and wiring plan
- set up the ESP32 development environment
- connect and test the RTC module
- connect and test the LCD display
- connect and test the push buttons
- connect and test the two servo motors
- define the RTOS task structure
- implement basic menu flow and status display
- update the wiki page with the approved proposal material
Week 2 — Minimal Working Prototype for Progress Demo
April 26, 2026 – April 29, 2026
- integrate RTC reading with the control workflow
- implement basic azimuth and elevation motion control
- display calculated time and tracking state on the LCD
- demonstrate a basic dual-axis movement prototype
- implement an initial RTOS-based separation of tasks
- prepare a short live demo showing basic tracking motion
By the end of this week, the system should be able to read time, compute a simple target position, and move both axes, even if tracking accuracy and stretch goals are still incomplete.
Week 3 — Complete Core Features
April 30, 2026 – May 6, 2026
- finalize solar angle calculation logic
- improve dual-servo control and synchronization
- refine azimuth and elevation tracking behavior
- improve LCD prompts and user interaction
- test multiple time-based tracking scenarios
- refine RTOS task interaction between timing, UI, control, and actuation
- document integration progress on the wiki
Week 4 — Final Integration, Testing, and Presentation
May 7, 2026 – May 13, 2026
- complete final subsystem integration
- perform end-to-end testing of the tracking system
- fix bugs and improve system stability
- refine LCD messages and motion behavior
- test dual-axis panel positioning under multiple conditions
- finalize prototype layout and presentation readiness
- complete the final wiki updates
- finalize slides and rehearse the demo