Tetris on the Green Building

In the 4 months leading up to April 2026, I worked with a team of students to turn MIT’s Green Building into a giant, playable game of Tetris. We achieved this by designing, building, and installing 153 custom radio-controlled modules, one mounted on each window.

Hacking has always been ingrained into MIT’s culture, and it has long been regarded as the “holy grail of hacks” to bring Tetris to the tallest building on campus. Facing across the Boston skyline, our display would be the largest video display visible to Boston.

This hack had actually been pulled over a decade ago in 2012, when a group of hackers successfully put Tetris on the Green Building using a fleet of LED modules as well. Unfortunately, due to factors such as condensation and unenclosed hardware, much of their hardware failed by 2018 when the installation stopped functioning. Our goal was to revive the hack while designing everything from scratch, building upon the lessons learned in the previous installation to last 10+ years.

Working with an incredible team that did PCB development/EE, hardware design, software, and sourcing, I was responsible for the firmware development, writing and testing the code for every module and the base station.

In April of 2026, for MIT’s Campus Preview Weekend, we hosted the grand reveal of our hack. Anhad, who led the project, put together a reveal compilation:

The display isn’t just limited to Tetris! Here is us playing Bad Apple:

Articles about our project were published in The Tech as well as MIT Admissions Blogs (check them out!!).

Overview

Our installation runs on 153 independent, fully custom, radio-controlled modules installed in every window, each with:

An LED board with alternating R, G, and B LEDs
A custom machined aluminum enclosure that holds all components and serves as a heatsink
An MCU board responsible for control, radio, temperature sensing, and NFC
A linear lens which casts the light onto the face of each window, and a glass plate on top
A snooze button so researchers working late in the building can temporarily shut off their window’s pixel Each module plugs into a standard outlet in every room. The modules all talk to a base station over encrypted 915MHz radio, where they receive color commands and reply with diagnostic data.

exploded view — Exploded view of a module

This project was started in November 2025, and the goal was to deploy it in time for Campus Preview Weekend in April 2026. This means all the designing, testing, and mass assembly would have to take place in a few short months, all while balancing schoolwork and clubs. In total, nearly $30k was spent on this project.

This was the first major group engineering project I had worked on, and the extraordinary scale and tight timeline made it quite exciting! I am so lucky to have worked with such an amazing team from diverse disciplines, and am incredibly grateful for their support along the way.

Firmware

I was the sole member responsible for firmware development on our STM32WL3 series microcontrollers. The firmware running on both base station and modules feature:

915MHz FSK radio for dual-way communication
- FEC (Forward Error Correction) on all packets
AES-128 encryption on all packets
Thermal throttling to regulate module temperature while maximizing brightness
NFC capability, allowing us to write module IDs (and other data) after the boards have been flashed and sealed up
30FPS operation

By far the most challenging aspects of my experience were interfacing with the 915MHz FSK radio between the base station and modules, and handling the encryption protocol.

Throughout those 4 months, I:

Designed and programmed a state machine on both base station + modules that:
- Integrated our encryption protocol, NFC, thermal throttling, and all other capabilities,
- Reliably swapped between RX/TX on both ends
- Safely handled any faults
- Allowed debugging from the ground
Worked to determine the optimal FSK type, datarate, bandwidth, transmit power, preamble length, and other radio parameters
Wrote radio test scripts that guided hardware decisions (antenna type and angle, LNA/PA on base station TX/RX, etc
Rigorously created and ran through a series of tests before sealing them shut…forever…for all of Boston to see…

As firmware and electrical hardware are interlinked, I spent much time working with Anhad, who designed the PCBs and did much of the EE/RF work.

Our AES-GCM encryption protocol ensures that the displays we put up are under strict security, preventing anyone from broadcasting displays to all of Boston that would get MIT in hot water. When we initialize operation, the base station individually authenticates each module, after which media can be sent with packets encrypted with a unique session key. I first tested this protocol with the base station and a singular module, and gradually scaled up in my tests to ensure a smooth initial authentication sweep and encrypted transmitting.

Testing authentication of 1 module with devboard base station

The state machine went hand-in-hand with the encryption protocol, and was quite fun to create. Our firmware architecture allowed us to send diagnostic requests from the ground and receive data on each module’s temperature, throttling, RSSI, and snooze status. I needed to be very careful in coordinating state transitions between the base station and modules, especially when transmitting and receiving. We also needed to be able to sync and tweak each module’s frame counter clocks, enter and exit debug mode (sync checking), and emergency shutoff (de-authenticate).

Testing and Mass Assembly

Testing took up the majority of the time I spent, and this project certainly showed me just how important testing was and how much time it took. There was a period of 2 weeks in March where nearly all I did was go to our makerspace, run tests, iterate, debug, and go to bed at sunrise. We ran rigorous tests on the state machine, module commands, accelerated lifetime testing (heat dissipation and thermal throttling), and much more.

Once we had our modules assembled, we took them to our makerspace and ran tests with all of them operational at once, identifying modules with issues (problem children) and trying to find the root causes. This room was absolutely insane. The modules drew almost 10kW in total, and you couldn’t look at the tables for more than a few seconds without needing to squint or put on sunglasses. The entire room also became a lot warmer from the modules’ heat.

While testing, I learned that even if the firmware was perfect in doing its job theoretically, it’s not enough - firmware runs on real hardware which can have issues, and when deadlines are tight, it’s firmware’s job to fix them too :)

One great thing about needing to mass produce our modules is that rare bugs that would have been harder to identify showed up a lot more frequently. When we have 160 identical modules running the same code at the same time, we can quickly identify and troubleshoot modules that are acting up, diagnosing the issue and seeing if it can be fixed in hardware or firmware. We spent a good while running tests in the room of the wrath of the sun.

In the last several weeks, testing and mass assembly ran simultaneously, all happening in our dorm’s makerspace. Finally, when we were confident in the modules’ performance, we sealed the modules up and prepared to deploy.

Anhad put together a testing compilation video here:

Gallery

Thanks

Thank you once again to the entire Tetris team and inviting me on this incredible journey with you! You should definitely check out Anhad’s and Vaughn’s writeups as well for more details about the project! If you would like to program custom games and displays for the Green Building, you should check out this repository👀

← Back to projects