Buses don't run on your schedule—they're late, they're early, and you're either rushing out the door or standing at the stop for 20 minutes. Our alarm clock syncs with live bus tracking to wake you at the perfect moment. Just set your stop, destination, and when you need to arrive—the clock handles the rest. For students trying to squeeze out every minute of sleep while still making it to class on time, it's peace of mind you can actually count on.

Inspiration

This project was born from personal frustration. After countless mornings of either waiting at a bus stop or sprinting out the door only to watch the bus pull away, we knew there had to be a better way. The choice was always the same: wake up way too early just to be safe, or risk being late to class. We wanted those extra minutes of sleep back—without the anxiety of missing our ride. SwampRise is the alarm clock we wished existed every time we groggily checked our phones at 6 AM, trying to figure out if we could sleep just a little longer.


What it does

SwampRise is a smart alarm clock that syncs with live GNV RTS bus tracking to wake you at the perfect time. During setup, you select your bus stop, destination, and arrival time—the clock handles everything else. It monitors real-time bus locations and automatically adjusts your wake-up time if buses are running late. It's designed around one simple goal: maximize sleep, minimize waiting, never be late."


How we built it

SwampRise runs on an ESP32 microcontroller with an LCD display showing the next two buses at your origin stop, four seven-segment displays showing the current time, and a Real Time Clock module for timekeeping. We reverse-engineered the riderts.app API by analyzing network requests and parsing their JavaScript to understand the authentication headers and request parameters—then built our own client in C++ to pull live bus data directly to the ESP32. The device also syncs with a time API on startup when connected to WiFi.

The entire system is built on ESP-IDF and FreeRTOS, giving us the low-level control needed for precise timing and concurrency. We leveraged both cores of the ESP32 to simultaneously handle RTC polling, display updates, API requests, and serving a web-based configuration UI—all running in parallel without blocking.


Challenges we ran into

Reverse-engineering the riderts.app API was our biggest technical hurdle. The web app didn't have public documentation, so we had to inspect network traffic, dig through minified JavaScript, and experiment with different request formats until we could reliably pull bus data. Getting the authentication and parameter structure right took hours of trial and error.

Concurrency on the ESP32 pushed us into territory we'd never explored. Running a web server, polling the RTC, refreshing the display, and making API calls simultaneously required careful FreeRTOS task management across both cores. We hit one key issue where the 7 segment refresh task was hogging all resources on one core, preventing another critical task from running, but once we moved that task to its own core, everything worked smoothly.

Working on different features in parallel hastened the development process, but presented significant difficulties with version control and integration. During the course of this hack, we learned how to better use GitHub, and work with others more effectively to accomplish an objective.


Accomplishments that we're proud of

None of us had built a complex project with the ESP32 before—we dove straight into ESP-IDF and FreeRTOS without the training wheels of Arduino IDE. Figuring out how to orchestrate multiple hardware components and network operations concurrently felt like solving a puzzle where every piece had to fit perfectly. Successfully reverse-engineering a production API and building a reliable client on embedded hardware was another huge win.


What we learned

This project was a crash course in embedded systems development. We learned how to work with ESP-IDF's component architecture, manage FreeRTOS tasks and synchronization primitives, and handle network operations on resource-constrained hardware. Reverse-engineering the API taught us how to analyze web traffic and understand authentication patterns. Most importantly, we learned that building hardware projects requires patience—debugging embedded systems is a completely different beast than debugging software.


What's next for SwampRise Bus Alarm

The next step is miniaturization. Right now, SwampRise is a collection of components on a breadboard—we want to design a custom PCB that integrates everything into a sleek, bedside alarm clock form factor. We're also planning a 3D-printed enclosure that looks like an actual product you'd want on your nightstand. Beyond that, we'd love to expand transit data sources to support other universities and cities, add features like weather-based adjustments (wake earlier if it's raining), and potentially integrate with smart home systems. If there's enough interest, maybe SwampRise becomes something students actually buy.


Built With

Share this project:

Updates