GlanceGo — A Smart e‑Ink Clock for Bus ETA Display

We’re excited to share our competition project GlanceGo, developed by our team across HKIS, SIS, Kellett, and The Pilgrims School (UK) — Sam, Mitchell, Saara, Jamie, and Zachary. Special thanks to Zach who is visiting from the UK and volunteered his time to help with the project.

Table of Contents

Background Story

Project Idea

Timeline & Hardware

Week 1

Week 2

Week 3

Week 4

Week 5

---

🌧️ Background Story by Chris

One cold winter night, I saw two elderly people standing at a bus stop. It was raining — the kind of slow, steady rain that sneaks under umbrellas. They looked cold and shaky, wrapped up in thin jackets, softly shivering in the dim streetlight.

I asked them how long they had been waiting. They said, “About thirty minutes.” That surprised me; the next bus wasn’t due for another five. I told them they could check the bus times on their phone, but they smiled politely and said they didn’t have a smartphone — and even if they did, they wouldn’t know how to use it.

That moment stuck with me. Their eyes, like so many elderly people’s, were tired and dim — screens and small text weren’t made for them. And yet, in our rush to design for the latest devices, we had somehow forgotten about them.

So that night, an idea started forming:what if there were a simple, caring display just for people like them?Something that didn’t need touchscreens, apps, or logins — just a gentle, comforting interface.

A small e‑paper display on the wall, always showing the next few bus arrivals, updated automatically. No need to reach for a phone, no tapping, no scrolling — just a quick glance, like checking a clock before leaving the house.

This project isn’t just about technology — it’s about inclusion. It’s a way to remind ourselves that good design should serve everyone: the elderly waiting in the rain, the busy parent rushing in the morning, or anyone who just wants to know, “When is my bus coming?”

A design that’s simple, useful, and full of care.

---

💡 Project Idea

Many elderly people find smartphones difficult to use or may not have them nearby. GlanceGo solves this by showing live bus arrival times directly on a 7.5‑inch e‑ink display mounted on the wall. The large, crisp digital clock also doubles as elegant home décor — simply glance to know both the time and when the next bus will arrive.

Why It Matters

• Glance‑based: Easy to read instantly from across the room.

• No learning curve: Ideal for elderly users who don’t use phones.

• Good décor: Clean and modern e‑ink display fits any living room.

• Accessibility: Saves walking or searching for a phone.

• Universal use: Convenient for any household member.

---

🗓️ Timeline

We aim to complete and test the final prototype by the end of December.

Stay tuned — we’ll share progress updates and demo photos soon.

⚙️ Hardware

Our setup uses:

• 7.5" Monochrome ePaper Display (800×480 Pixels)

  
  

  → a power‑efficient e‑ink screen with sharp black‑and‑white visuals that stays clear even under sunlight.

• XIAO ePaper Display Board EE04 | ESP32‑S3 Plus

  
  

  → compact controller board supporting 24‑pin / 50‑pin displays, running network code to fetch bus data and update the screen.

Together, these components make the system low‑power, always readable, and simple to maintain.

---

🗓️ Project Journal — Week 1

Summary:This week, we successfully displayed real‑time bus arrival times on a 2.7‑inch e‑Paper display powered by a Raspberry Pi. The system fetches live data from the Citybus API and updates automatically every minute. The information shown — bus number and estimated arrival time — has proven to be accurate and reliable.

Design & Implementation:The layout is clean, minimal, and easy to read, designed with elderly users in mind.Huge thanks to Mitchell and Zach for creating the user interface layout and overall visual design, and to Sam for writing the code that drives the data fetching, timing logic, and e‑ink rendering.

Current Hardware:We are currently using a 2.7‑inch Waveshare e‑Paper HAT, but the 7‑inch version (intended for the final product) has not yet arrived.The larger size will be critical for the elderly audience — allowing larger fonts, better spacing, and enhanced clarity.

Next‑Step Considerations:At this stage, we’re still running everything on the Raspberry Pi, which works well for prototyping but is relatively costly for deployment. To reduce costs, our plan is to migrate to an ESP32 controller, but we still need to confirm if it is fully compatible with e‑Paper displays and whether it can handle the data updates reliably over Wi‑Fi.

Challenges Ahead:One key challenge is making setup simple for elderly users.The device requires a Wi‑Fi connection and bus route configuration, yet the Raspberry Pi currently operates without a keyboard or mouse. We’ll need to explore an easy network setup process — possibly through a captive portal (like a smartphone Wi‑Fi setup page) or a dedicated companion app — so that users can:

• Connect the device to their home Wi‑Fi.

• Select which bus routes to monitor.

Next Week’s Goals:

1. Test compatibility of an ESP32 board with the e‑Paper display.

2. Develop a simple Wi‑Fi setup interface.

3. Begin planning the user configuration workflow (bus number and stop selection).

4. Continue refining the display layout once the 7‑inch e‑Paper arrives.

---

🗓️ Project Journal — Week 2

We are using Autodesk Fusion to design a custom enclosure for the e‑paper display.

Special thanks to Zachary for taking precise measurements and leading the enclosure design work.

This week’s focus:

• Designing and 3D‑printing the first enclosure prototype

• Planning a simple configuration interface to let users choose networks and bus routes easily

  
  

3D Printing Enclosure

Configuration interface

When we started figuring out how to connect our Raspberry Pi to Wi‑Fi, it seemed simple—until we realized there’s no screen or keyboard. We needed an easy setup for elderly users. We thought about how CCTV cameras and smart devices connect: they create their own hotspot, you join it with your phone, and input your home Wi‑Fi credentials. That idea clicked instantly. We could do the same! So we planned a “GlanceGo_Setup” network that opens a small webpage where users enter their Wi‑Fi and bus stop once. After reboot, the Pi connects automatically—simple, intuitive, and perfect for anyone to use.

For elderly users, our goal is “plug‑and‑forget”:

• Setup happens once via phone.

• Then the display works permanently as long as Wi‑Fi remains available.

This approach is almost identical to how consumer IoT devices work, but we retain full control and local data privacy. Here is what the flow will be like:

---

🗓️ Project Journal — Week 3

This week marked a major turning point for our project — both exciting and challenging.

ePaper display

Our 7.5‑inch ePaper display finally arrived, and seeing it in person instantly reignited our motivation. It felt like a huge step closer to the finish line. We immediately set it up with the Seeed Studio XIAO ESP32‑S3 Plus on the EE04 ePaper controller, eager to bring our data display ideas to life.

This new hardware direction also led to a big shift in our development process. We decided to transition from Python on Raspberry Pi to C++ on ESP32. It’s admittedly a steep learning curve — moving from a single‑board computer with a full operating system to a microcontroller requires a different mindset. Handling Wi‑Fi, HTTP requests, and display control manually felt daunting at first. Still, we knew this switch was the right move. The microcontroller solution drastically lowers cost and power consumption, aligning better with our long‑term goals.

The week was filled with trial and error — endless attempts that didn’t quite work, confusing library errors, and an ePaper screen that stubbornly stayed blank. After several long sessions, we finally managed to display text successfully on the screen. It may seem small, but that simple result was a huge emotional win.

3D print stand

With the display working, we turned to the hardware design. Using Autodesk Fusion 360, we modeled a custom case with a built‑in stand. The 3D print came out beautifully — sleek, balanced, and surprisingly polished. For the first time, our idea looked like a real product.

Fetch Real‑Time bus ETA

From there, we focused on connectivity. We wrote and tested C++ code to connect the ESP32‑S3 Plus to Wi‑Fi. Seeing the serial monitor return an IP address was immensely satisfying — one more barrier down. Deepening our confidence, we then used C++ to call the Citybus API online and fetch real‑time bus ETA data. The ESP32 printed actual arrival times to the serial monitor—proof that our system could now retrieve live data.

Overall, Week 3 was filled with breakthroughs and learning. The journey from Python to C++ wasn’t easy, but every failure taught us something valuable. We ended the week with a functional display, working internet connection, and real bus information printed out.

The next big milestone is clear:

Show all bus ETAs directly on the ePaper display.

We’re closer than ever to turning our idea into a finished, connected, real‑world device.

---

🗓️ Project Journal — Week 4

Making OpenDyslexic Work on the OLED

OpenDyslexic fonts improve readability by adding weighted bottoms and distinct letter shapes, reducing letter flipping and eye strain. For the elderly and frequent readers, these features stabilize visual focus, enhance word recognition, and lessen fatigue—making text easier to follow on screens or paper through clearer visual differentiation and spacing.

OpenDyslexic fonts improve readability by adding weighted bottoms and distinct letter shapes, reducing letter flipping and eye strain.

Our goal was to display text in the OpenDyslexic font on an Arduino OLED for improved accessibility. The challenge: Adafruit GFX doesn’t accept .ttf fonts, only its own .h GFXfont format.

I found the hidden fontconvert tool inside the Adafruit GFX folder and spent hours troubleshooting missing dependencies and compiler errors. The breakthrough came after installing FreeType and successfully building the converter with:

sudo apt install libfreetype6-dev && make.

./fontconvert OpenDyslexic-Regular.ttf 12 > OpenDyslexic_Regular12pt7b.h

generated the needed header file. The next obstacle was a naming mismatch — the header defined the font as open_dyslexic12pt7b, not OpenDyslexic_Regular12pt7b. Editing the code to use the correct variable finally made it compile.

When the OLED lit up with crisp OpenDyslexic letters, the frustration instantly became satisfaction. The font is lighter on the eyes and readable even on the tiny 0.96‑inch screen.

Next, we’ll reuse the same header on the ePaper display, where higher resolution and natural contrast should make the OpenDyslexic type even clearer — a small but meaningful win for accessibility in our project.

---

🗓️ Project Journal — Week 5

Overview

This week was a major step forward for the GlanceGo assistive transit display project.We successfully integrated Open Dyslexic fonts onto the ePaper screen, refined the UI for accessibility, and improved overall device usability and readability.

Key Achievements

1. Open Dyslexic Font Integration

We finally managed to display Open Dyslexic Regular, Bold, and Heavy fonts on the ePaper screen — a huge improvement for legibility, especially for elderly or dyslexic users.

Process summary:

1. Converted the .otf font files to .ttf format using an online OTF → TTF converter (to make them compatible with embedded systems).

2. Used the Adafruit GFX Font Conversion tool you suggested to generate .h font files.

   • Adjusted font size and character ranges for memory efficiency.

3. Included the converted fonts in the firmware and configured the display code to select the proper font using setFreeFont().

4. Tested rendering on the Seeed ePaper / GFX library until spacing and text‑weight were visually balanced.

It took a lot of troubleshooting and research — mapping font baselines, adjusting bounding boxes, and testing contrast levels — but the payoff was worth it. The new text renders beautifully clear and comfortable to read.

 2. UI Redesign for Accessibility

We made a full pass on layout and readability:

• The first ETA time now uses bolder, thicker lines, while the second ETA is lighter — improving eye guidance through contrast.

• Added horizontal guide lines separating each bus row.

• Revised the column spacing and alignment to create consistent visual flow.

• Combined with the Open Dyslexic fonts, the new design feels calm, readable, and senior‑friendly.

• Added real‑time clock feature using internet‑based NTP synchronization

 3. Wi‑Fi Indicator and Improved Header

We added a custom‑drawn Wi‑Fi icon (vector arcs in Seeed GFX) to the header section.It shows network status at a glance — a small but powerful diagnostic and UX improvement.

We later scaled it to be more visible and balanced it above the time display.

 4. New 3D Holder Design

A second iteration of the 3D‑printed holder was completed to improve device stability and readability angle.The updated casing provides better cable management and cleaner integration of the ePaper panel and control board.

Reflection

This week’s success proves our team’s persistence truly pays off. We spent countless hours investigating why the ePaper display suddenly stopped working, even when using our previously functional code. The screen went completely blank — no errors, no responses. It made us doubt everything we had built so far: the wiring, the firmware, the display, even the code logic.

We tried different sketches, checked connections, swapped hardware, and reviewed forum posts. Nothing worked. Eventually, we went back to the documentation and read every line of the datasheet and library notes word by word. After deeper research and careful comparison, we discovered the hidden cause:a library conflict between epi_tft and Seeed GFX. Both shared similar function names, which silently interfered with each other — the IDE didn’t flag any errors, but the wrong library was being linked.

By removing the epi_tft library and keeping only the Seeed GFX version, everything came back to life immediately. The display worked perfectly again.

This experience reminded us how subtle software conflicts can completely block hardware progress — and how critical it is to trace dependencies carefully. Now, with the display, fonts, and layout all working smoothly, we have a stable visual foundation for GlanceGo. The next steps will focus on intelligence, connectivity, and easy setup — moving us closer to a true “open box and use immediately” product experience.