The problem
A two-wheeler rider can only look down at the cluster for a fraction of a second, yet many EV clusters crowd SOC, range, mode, speed and warnings onto a small screen. Layout decisions are often made by taste rather than by measured glance legibility, which costs attention at exactly the moments the rider can least afford it.
Objectives
- Design at least four cluster layouts (text-only, icon-plus-number, priority-first and a dense baseline) for the 16×2 LCD and the OLED.
- Build firmware that shows a layout for a fixed exposure time, blanks it and captures the participant's answer on the keypad or buttons.
- Log trial-level data (layout, exposure, correct/incorrect, response time) over UART to a PC.
- Run a small within-subjects study and compare layouts with repeated-measures statistics.
- Turn the results into layout guidelines for a low-resolution EV cluster.
What you need
From the EV Embedded Development Kit
- 16×2 LCD
- BMS OLED and six navigation buttons
- 4×3 matrix keypad
- RGB LEDs
- Buzzer
- Serial UART interface
- STM32F103C8T6 main controller
- Smart BMS unit STM32F103C8T6
Software
- STM32CubeIDE with HAL drivers
- Embedded C
- Python 3 with pyserial, pandas, SciPy and matplotlib
- A statistics package or Python statsmodels for repeated-measures analysis
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
- Glance legibility
- How much correct information a person extracts from a display in a single short look. It is measured with brief, controlled exposures rather than by asking people which design they like.
- Tachistoscopic presentation
- Showing a stimulus for a precise, short time and then masking or blanking it. On the kit a hardware timer controls the exposure so it does not drift with other code.
- Within-subjects design
- Every participant sees every layout, so differences between people cancel out. The order must be counterbalanced, for example with a Latin square, to stop learning effects favouring later layouts.
- Speed-accuracy trade-off
- People can answer faster by guessing. Reporting both response time and error rate, or a combined measure, avoids rewarding a layout that only looks fast.
Step-by-step guide
- 1
Define the questions and the information set
Decide what a rider must read at a glance: speed, SOC, riding mode, range and one active warning. Write down the research questions, for example whether a priority-first layout gives fewer reading errors than a dense layout at 500 ms exposure. Choose the independent variables (layout, exposure time, display type) and dependent variables (accuracy, response time). Draft the participant procedure and consent form and check with your department whether ethics review is needed for a study with human participants.
Checkpoint: A one-page study protocol listing variables, hypotheses, trial count per participant and the consent wording, agreed with your guide.
- 2
Design the layouts on paper
Sketch each layout on a 16×2 grid and on a 128-pixel-wide OLED canvas (confirm the OLED resolution and controller from the kit manual; SSD1306-class 128×64 is common). Use custom LCD characters (CGRAM holds eight 5×8 glyphs) for battery and warning icons. Keep a deliberately dense baseline that resembles a cluttered production layout. Fix character positions so the same value always appears in the same place within a layout, because spatial consistency is part of what you are testing.
Checkpoint: Grid drawings for at least four layouts on each display, with every glyph defined bit by bit.
- 3
Configure the boards in CubeMX
On the main controller enable the GPIO pins for the 16×2 LCD (4-bit mode) and the 4×3 keypad, USART for the PC link at 115200 baud and a basic timer (for example TIM2) at 1 kHz for exposure timing. On the Smart BMS unit enable I2C for the OLED and GPIO inputs for the six navigation buttons. Set DIP switches to connect only the LCD, keypad, RGB LEDs and buzzer blocks needed. Set the clock tree to 72 MHz from the external crystal on both boards.
Checkpoint: Both projects build and a test pattern appears on the LCD and the OLED after flashing.
- 4
Write display and input drivers
Write a non-blocking LCD driver that writes a whole frame buffer in one call and an OLED driver that pushes a 1 KB frame over I2C (HAL_I2C_Mem_Write or DMA). Measure how long a full update takes, because a slow update smears the exposure onset. Scan the keypad every 5 ms with a debounce of three consistent reads and timestamp the first valid key press using the 1 kHz timer tick. Do the same for the six buttons on the BMS unit.
Checkpoint: Logic or GPIO-toggle timing shows a full LCD update and OLED update time, both recorded in your log book, and key presses are timestamped to 1 ms.
- 5
Build the trial sequencer
Implement a state machine: fixation (a centre mark for 1 s), stimulus (layout with randomised values for the set exposure time), blank, question prompt (for example, 'SOC above 50?' or 'Which warning?'), response, then inter-trial pause. Generate values from a seeded pseudo-random generator so each trial is reproducible. A short buzzer tick marks stimulus onset if you want an audio cue; keep it identical across layouts.
Checkpoint: A dry run of 20 trials completes without manual intervention and the sequence repeats exactly when the seed is reused.
- 6
Log trials to the PC
Send one CSV line per trial over UART: participant ID, trial number, layout, display, exposure in ms, true value, answer, correct flag and response time. Write a Python logger that saves each session to its own file and checks for missing trial numbers. Add a session header with firmware version and seed so the data can be traced back later.
Checkpoint: A pilot session file opens in pandas with the expected number of rows and no gaps in trial numbers.
- 7
Add a secondary task to mimic riding
A rider is not only reading the cluster. Run a simple PC-side tracking task (keep a moving dot inside a band with the arrow keys) and trigger cluster glances during it, or have the participant keep a steady potentiometer position as a stand-in throttle task. Record tracking error around each glance. This makes the study closer to the real situation while staying safe on a desk.
Checkpoint: Pilot data show tracking error rising during glances, confirming the dual-task setup is working.
- 8
Pilot, counterbalance and run the study
Pilot with two or three people, fix confusing questions and set exposure levels so accuracy is neither near 100 per cent nor at chance. Counterbalance layout order with a Latin square. Run the main study with the number of participants your guide agrees on, keeping lighting, viewing distance and instructions constant. Record any deviations in a lab sheet. Seat every participant at the same distance and angle from the displays, and give them a short practice block that is not analysed.
Checkpoint: Complete data for every participant and every layout, with the order table and deviation log saved alongside.
- 9
Analyse the results
Compute per-participant accuracy and median correct-response time for each layout and exposure. Check normality, then use repeated-measures ANOVA or the Friedman test, with corrected post-hoc comparisons. Report effect sizes and confidence intervals, not just p-values. Plot accuracy against exposure time for each layout to see where each one breaks down. Exclude trials only by rules written before the analysis, such as response times under 150 ms, and report how many were excluded. Keep the notebook under version control so every figure can be traced to a commit.
Checkpoint: A results table and accuracy-versus-exposure plot, with the statistical tests named and reproducible from a Python notebook.
- 10
Write guidelines and the report
Translate findings into practical guidance: which information to fix in position, where icons beat text, how many items can be read in one glance at your exposure levels. Discuss limitations honestly, such as desk setting, small sample and display size. Include the firmware, analysis notebook and raw data in the project archive. Link each guideline to the specific result that supports it, and say where the evidence is weak. Add photographs of every layout on the real displays, because screenshots of the design grid do not show contrast and viewing-angle effects.
Checkpoint: The report presents hypotheses, method, results and guidelines, and another student can rerun the analysis from the archived files.
Testing & validation
- Exposure time measured with a GPIO toggle against a timer reference is within ±2 ms of the set value on both displays.
- Response timestamps are verified against a known delay injected by a test key-press routine.
- Pilot accuracy at the chosen exposure times sits between chance and ceiling for every layout.
- Analysis reproduces identical numbers when rerun from the raw CSV files.
Expected results
A working glance-test rig, a dataset of trial-level responses for several cluster layouts, statistical comparison against a dense baseline layout and a short set of evidence-based layout guidelines for low-resolution EV clusters.
Research angle for your M.Tech thesis
Research questions: does a priority-first layout reduce reading errors and dual-task interference compared with a dense baseline, and how does the benefit change with exposure time? Metrics: accuracy, median correct-response time, tracking error during glances and subjective workload. Baseline: the dense layout. A publishable study would preregister hypotheses, use a justified sample size, counterbalance properly, report effect sizes and share the protocol so others can replicate it on similar low-cost displays.
Take it further
- Add a vibration condition by asking participants to hold the board while a PC-side cue makes them move, and use the MPU6050 to log the motion.
- Compare colour-coded RGB LED tell-tales against on-screen warning text.
- Fit a model of accuracy versus exposure time to estimate the glance time each layout needs.
Viva and review questions
Why did you use a hardware timer for the exposure instead of HAL_Delay?
HAL_Delay blocks and depends on the SysTick tick and other interrupts, so the exposure could stretch. A timer gives a fixed 1 ms base and lets the input scanning keep running.
How did you stop learning effects biasing the comparison?
Layout order was counterbalanced with a Latin square, and practice trials were run before the measured blocks.
Why report both accuracy and response time?
A layout can look fast because people guess. Reporting both shows whether a speed gain came at the cost of more errors.
What limits how far your findings generalise?
A desk setting, a small sample and small displays. Results show relative differences between layouts rather than real-road glance times.