The problem
Many electricity tariffs are cheaper at night, and grid operators prefer EV charging to move away from the evening peak. Simple timers are easily disturbed by power cuts or clock drift. A vehicle-side scheduler needs a reliable clock, a clear user interface and rules that still guarantee the vehicle is charged when the owner needs it.
Objectives
- Keep reliable time with the RTC and its CR2032 backup, including across power loss
- Let the user set an off-peak window and a departure time on the keypad
- Decide when to start charging so the cell is charged by departure, preferring the off-peak window
- Control the charge relay, show status on the LCD and keep a short session history
What you need
From the EV Embedded Development Kit
- STM32F103C8T6 microcontroller unit (main controller)
- Second STM32F103C8T6 as the Smart BMS unit
- RTC with CR2032 backup cell
- 4×3 matrix keypad
- 16×2 LCD
- 1S battery with connector and T-sense input
- Battery charging unit with its own switch
- Charge/discharge control relay
- RGB LEDs and a buzzer
Software
- STM32CubeIDE with HAL drivers
- Embedded C
- Python (optional, for plotting session logs)
Extra parts
None. Everything this project needs is on the kit.
This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.
Key concepts
- Time-of-use tariff
- A tariff with different prices for different hours. A scheduler shifts flexible loads such as charging into the cheaper hours.
- Battery-backed RTC
- A clock chip that keeps counting from a coin cell when main power is off, so the schedule stays correct after a power cut.
- Latest start time
- The latest time charging can begin and still finish by departure, computed from the energy needed and the expected charge rate plus a margin.
- BCD time registers
- Many RTC chips store seconds, minutes and hours as binary-coded decimal, so each nibble holds one decimal digit and must be converted.
Step-by-step guide
- 1
Requirements and user stories
Write user stories: set the clock, set an off-peak window such as 22:00 to 06:00, set a departure time, choose 'charge now' to override, and see the next planned start. Define behaviour after a power cut and when the window is too short to finish. Estimate the charge time for the kit cell from its capacity and the charging unit's current, and add a margin. Note cell safety: check polarity, never short the cell and do not leave charging unattended.
Checkpoint: A requirements list with at least eight testable statements, including power-cut behaviour.
- 2
Board setup and RTC bring-up
Enable the DIP switches for the RTC, keypad, LCD, LEDs, buzzer, battery, charger and relay blocks. Configure I2C on the main controller and run a bus scan to find the RTC address. Read the time registers, convert from BCD and print the time over UART once a second. Write a set-time routine that writes BCD values and clears any oscillator-stop flag the chip provides.
Checkpoint: The clock keeps time over an hour within a few seconds of a phone clock and continues after the board is switched off and on.
- 3
Keypad and LCD drivers
Drive the 4×3 keypad rows as outputs and read the columns with pull-ups, scanning every 10 ms with a debounce of about 30 ms. Drive the 16×2 LCD in 4-bit mode and write helpers for printing a time and a two-line menu. Implement numeric entry of HH:MM with '*' as back and '#' as enter, and validate the input. Show a blinking cursor at the digit being edited so the user always knows where they are.
Checkpoint: The user can enter 22:30 on the keypad and see it echoed correctly, and invalid entries such as 25:70 are rejected.
- 4
Persistent settings
Store the window, departure time and mode so they survive power loss. Use the RTC chip's battery-backed RAM if it has some, or the STM32's backup registers, or a flash page on the controller with a simple checksum. Load and validate settings at start-up and fall back to safe defaults if the checksum fails. Write settings only when they change, not continuously, so that flash wear is not a concern over the life of the product.
Checkpoint: Settings entered before a power cycle are restored afterwards, and a corrupted checksum restores defaults with a message on the LCD.
- 5
Scheduling logic
Estimate the charge needed from the cell's resting voltage using a simple voltage-to-SOC table and the charge rate. Compute the latest start time that finishes before departure. If the latest start falls inside the off-peak window, start at the window opening or the latest start, whichever finishes in time with least peak use. If the window cannot finish the charge, start early enough to meet departure and flag it. Handle windows that cross midnight.
Checkpoint: A table of at least ten test cases, including midnight crossings and too-short windows, gives the expected start time when run in a test build.
- 6
Relay control via the BMS unit
Check the kit schematic for which controller drives the charge/discharge relay. If it is the BMS unit, send a simple command over the UART link between the controllers: charge enable, charge disable and a status request. The BMS unit applies its own voltage and temperature checks before closing the relay, so the scheduler can request charging but cannot override protection.
Checkpoint: Scheduler commands open and close the relay, and the BMS unit refuses to charge when the temperature reading is outside its window.
- 7
Status display and overrides
Show the current time, mode and next start on the LCD. Use an RGB LED: amber for waiting, blue for charging, green for done. Add 'charge now' and 'cancel' keys. Sound the buzzer briefly on the start and end of a session. Make overrides time-limited: 'charge now' should return to the schedule after the session ends, so the user does not forget the scheduler is bypassed. Show the reason when a scheduled start is skipped.
Checkpoint: Each mode is visible on the LCD and LED, and the overrides take effect within a second.
- 8
Session history
Record start time, end time, start voltage, end voltage and reason for each session in a small ring buffer in persistent storage. Add a menu to scroll through the last few sessions. Optionally print the history over UART as CSV for plotting. Include the reason a session ended, such as completed, cancelled, fault or power cut, because that is what a user or technician most often wants to know when a vehicle was not charged as expected.
Checkpoint: After three sessions, the history menu shows all three with correct times.
- 9
End-to-end test and report
Test with a shortened window set a few minutes ahead so you can watch a full cycle. Test a power cut during waiting and during charging, and confirm the scheduler resumes correctly. Measure clock drift over several days. Document the design, test cases, results and limitations, such as the simple SOC estimate. Record each test with the time set, the expected and observed start, and any deviation explained.
Checkpoint: A test log shows every requirement passed or explains why not.
Testing & validation
- Scheduler test cases including midnight crossings and windows too short to complete
- Power-cut tests during waiting and during charging
- RTC drift measured over several days
- Protection check: the BMS unit refuses charging out of its temperature or voltage window even when scheduled
Expected results
A keypad-and-LCD charging scheduler that keeps time across power cuts, starts charging in the off-peak window, finishes by departure where possible, and keeps a session history.
Take it further
- Accept tariff windows over Bluetooth with an HC-05 module add-on
- Add a multi-rate tariff table and minimise estimated cost
- Report schedule and state over CAN as a charging unit would to a vehicle control unit
- Use measured charge time from past sessions to improve the start estimate
Viva and review questions
What happens to the schedule after a power cut?
The RTC keeps running from the coin cell and the settings are stored with a checksum, so at power-up the scheduler reloads them and recalculates the next start from the current time.
How do you handle a window that crosses midnight?
Times are converted to minutes after midnight and the window is treated as two parts when its end is earlier than its start.
Why does the BMS unit check limits even when the scheduler asks to charge?
Protection must not depend on the scheduler. Separating the request from the safety decision means a scheduling bug cannot cause an unsafe charge.