Company/Group: Cedars Sinai, Center for Surgical Innovation and Engineering (CSIE)
Company/Group description: Integrating the concepts of engineering, physics, artificial intelligence, and data science with clinical science to develop better biomedical devices and wearables for solving health challenges. (Taken from https://cscsie.com/)
Role Title: Clinical Research Associate
Role description: Firmware developer and analog electronics designer
Duration: January 2024 - Present
Deliverables:
Designed, troubleshooted, and built first prototype of THOR (Testbed for Human Orthopedic Reflexes) and THOR MVP (Minimum Viable Product)
THOR MVP is a WIP and will be demoed to an investor in October 2025! Stay tuned.
Clinical trials have begun on the pressure plate (different project) and are planned for THOR post-September with the second prototype
Developed method of comparing individual reflexes by stretch and contraction time
My most recent demo (as of September 2025)
Watch it to see how to use our device!
Summer 2025
Design, tested, and built THOR MVP
Improvements over first prototype:
Modular PCB design
Rechargable battery (system power consumption: 2.5W)
Wireless data transmission (WiFi)
No wired connection needed, ever
Can connect to multiple devices without re-uploading micocontroller code
Ability to cancel data transmission if you want to re-do and override a failed reflex test
Sensor sampling improvements
More sensor channels (reading x5 channels instead of x2)
Increased sampling rate (+50% improvement) per channel
Increased sampling time (captures 2 seconds of a reflex vs 0.5 seconds)
Increased data storage (from 270 kB on 1st prototype to 22 MB on MVP)
Includes custom EMG circuit and cuff (designed with Rachel Reyes and Miguel Hernandez)
Custom reusable EMG electrodes instead of disposable gel pads
Increased robustness and reliability
Usable by people who aren't me, haha
Documentation for non-engineers to use
Android and iOS app for clinicians (designed by Kite Ogawa and Brandon Bright)
Includes calibraton modes to help the user align the THOR cuff correctly and test the THOR hammer sensitivity
Windows app for researchers (as opposed to Python script last year)
Summer 2024
Design, tested, and built first prototype of THOR (Testbed for Human Orthopedic Reflexes) -- an Arduino-based box that measures a subject's reflex in real time
This includes: programming of the Arduinos, design of the circuits (from breadboard to PCB), wiring of the hammer and cuff, construction of the hammer. Rachel Reyes printed and constructed the cuffs.
Conducted experiments to confirm the ultrasonic changes we were seeing was actually a muscle contraction due to reflex
Developed method of comparing individual reflexes by stretch and contraction time
AAAS February 2025 (Boston, MA)
Student E-poster competition presenter
First prize in Undegraduate Medicine and Public Health category
Submitted poster
ORS February 2025 (Phoenix, AZ)
Poster presenter
Submitted abstract, submitted poster
The below contain all (non-confidential)! technial details of my work.
Video of MVP in action (desktop version)
Video of THOR first prototype in action.
Desktop app GUI
EMG testing in progress (see breadboarded EMG circuit and disposable pad electrodes)
First cuff with custom EMG integrated
Final version of prototype
Raw cuff signals
Assembled protoboard
1st prototype PCB (never fabricated due to adminstrative overhead)
New team, new goals, new experience
This year, our team expanded and grew in more ways than one. We went from 10 people in the entire lab to over 10 people on just this project. We went from a half-empty workbenches in the corner of the PDC to running our first clinical trials. We went from our P.I's brainchild to a fully-fledged prototyping lab.
Accepting my return offer, I thought I'd just be doing a repeat of what I did last year: a mix of analog design, firmware tweaks, and a lot of experiment-running and data analysis. But this year, thanks to our bigger team, a lot of tasks became compartementalized. We had dedicated people to design and conduct clinical studies, dedicated people to make our software look pretty and usable, dedicated people to look at the data and ponder the numbers. Now all I had to do was focus on the electronics and firmware and optimize them as much as possible.
Our lab's productivity since implementing standup meetings, according to our P.I.
If last summer taught me the culture of research, this summer gave me a glimpse into start-up culture. We had a product to make, and that, our P.I. repeatedly reminded us, trumped all else. Pondering over several design choices? Choose one that works and move on. Some feature can be further optimized? Later problem—make sure it’s robust first. Daily stand-ups. Excel sheets of milestones. Early mornings and late nights. I once watched a fellow intern work a twelve-hour day...because I stayed for twelve hours too. No one was enforcing our hours, but looming deadlines and finicky bugs kept us working hard.
But that intensity also meant rapid progress. We didn’t just talk about ideas—we built them, tested them, revised them. We always had a usable version of the product in hand, even if it wasn’t perfect yet. Every week brought visible changes, and there was a kind of satisfaction in that momentum. Seeing a system go from half-broken breadboard to polished prototype in just a few weeks made the overtime hours feel worth it.
At the time of writing this, I’m on vacation (work hard, play hard!), and when I return, we’ll be heading into beta testing. That’ll be another change of pace, another set of challenges, and another opportunity to learn. And I’m excited for it.
At the beach on a Wednesday evening because I have free will
A Life Outside the Lab
All I did last summer after work was sit in my apartment. That is, until one day I heard my roommate crying on the phone in the other room. She sobbed that she almost never saw her friends or went out anymore—not because she didn’t want to, but because she was afraid of spending money, even though she was living below her means. Just a few years out of college, she was already feeling the trudge and sludge of working life. And that scared me.
This summer felt like my final "trial run" of adult life before I settle into it for real after graduation. (Well, unless I go to grad school, but let’s not think about that yet.) So despite living farther from work and having longer hours than last summer, I vowed to make this one more meaningful. I ate lunch in the park across the street instead of at my desk. I visited touristy spots around the city just because I could. I tracked down the accessible pianos at UCLA and practiced them. I made plans with old friends when I made it home on weekends.
Work-life balance isn’t something that comes from a certain kind of job. It’s something you carve out for yourself, especially in a city as full of life as LA.
Bridging the Software-Hardware Gap
This summer marked my first time working closely with software engineers. Up until now, I’d mostly worked with mechanical engineers, where our collaboration was straightforward—I’d give them board dimensions and connector placements, and we were done. Software, though, is a different beast.
Firmware wasn’t just a tool to get the hardware working anymore—it was a product interface. I had to tailor it to the needs of the software team: strip it down to just the functions they needed, refactor it for readability, and even walk them through how to run it on the physical hardware. It was more collaboration than I was used to, and it forced me to look at my own code differently. Instead of writing quick, scrappy functions that only I would read, I had to start writing as if someone else’s work depended on mine — because it did.
Anway, most of our integration is done, and now the software interns can run my electronics box without me being there at all! Did they somehow manage to completely drain our battery in a day? And fry the Arduino too? Yes. But hey, that's testing! And feedback for me to update the warnings in my documentation guide...
Shared Github = shared suffering
The senior EE explaining why I need to make another infinitestimally small change to my silkscreen and re-zip my gerbers for the 20th time
Mentorship, in Different Forms
Another first: this was my first time working with a senior electrical engineer. I expected detailed feedback on my circuit design or new ways to optimize layouts. But what he taught me was just as valuable—he introduced me to the standards of the field. With our lab now outsourcing to a U.S.-based PCB fabrication company, I had to step up my documentation game. He walked me through best practices for silkscreen labeling, draftsman drawings, and the kind of clean documentation expected in industry.
He wasn’t around every day—he had his own project to run—and I often had to troubleshoot independently. At one point, I was tasked with finishing and debugging an EMG system he’d started. It was a critical component for our MVP (minimum viable product), and it wasn’t working. After some long experiments and a few key design changes, I got it functional. That moment reminded me that mentorship doesn’t always look like hands-on guidance. Sometimes, it’s the foundation someone gives you that allows you to go further on your own.
Search for a sublease last-minute.
Seriously.
Usually, I'm the kind of person who likes to figure out logistics way ahead of time. But my summer roommate canceled on my and my subleaser found out it was actually not legal to sublease in his apartment. So oops, there I was, apartment-hunting two weeks before my internship.
And boom! Landed a single room in a (mostly) empty apartment all to myself, with super nice amenties, all for 20% less than what I had paid to share a small room with no amenities last summer. While setting up calls and tours during my finals week wasn't fun, I knew the UCLA subleasers were having even less fun trying to find subletters last minute too, and managed to haggle a good deal.
Also, paid parking is overrated...street parking for the win! I don't mind getting a few extra steps in.
Cat near my apartment
Snowed in at the Logan airport after the conference
Science communication is a skill of its own...
...and it really helps when you're passionate about the science you're communicating!
I've never really been into the research scene. So when my mentor suggested I apply for the AAAS poster competition, I was a bit hesistant. Me, who didn't want to touch academia with a ten-foot pole, in a national research competition?
However, I had a lot of support. My mentor assured me our lab had a good track record with this competition and he had high hopes of this having a positive impact on my future. I was taking SEC 10, a scientific communcation class that gave me the confidence to speak about anything convoluted in digestable terms. Professor Gold, who taught SEC 10, helped me fine-tune my presentation and encouraged me to take pride in my work. Most of all, this was the first research project that's felt really meaningful to me personally and I was excited to talk about it.
When I got to the competition, I was competing against students with projects they had been working on for years, and presenting to a panel of judges who didn't know a wink about engineering. Yet, I won. Just goes to show you don't need eons of experience or life-changing innovation to tell people you're doing exciting work.
Conferences are just hangouts for nerds
Ok, they're not *just* hangouts. I networked a bit. Looked at some very cool posters that did similar work to my lab's. Went to some talks, observed researchers get into heated discussions over methods...
...but come on, they were serving drinks at the poster expo! And livestreaming the Super Bowl too!
"Aren't conferences supposed to be intellectual meetings between stuffy academics?" I asked my mentor.
"They're really just hangouts for nerds," he said.
I also hung out with my fellow nerds (coworkers)! I got to learn their life stories and how they joined the company and even got big-sister-esque advice from my co-workers who shared a hotel room with me.
Conferences are cool, and they're not as scary and serious as I thought they would be. Very glad my first one was with this lab!
Everyone watching the Super Bowl instead of looking at my poster :(
Sunrise over the electrical workstation where I often worked
Independent, but not alone
One of my primary fears joining this lab was that I was the only person with an electrical engineering background, and thus no one would be able to point out my design flaws, help me when I got stuck, or progess as an engineer at all. This was not entirely the case. Although I often troubleshot by myself (because no one else had the background to debug the system that, well, I designed...), my mentors were with me every other step of the way.
For one thing, both my mentors are (mechanical) engineers. Thus, they helped me decide the scope of the problem, the timeline of building the first prototype, workarounds for sub-optimal functionality, quality requirements, etc. I was also able to relay to them the kinds of problems I was having (e.g. noise, low sampling rate, etc) and have them help me brainstorm next steps.
They also have a much more extensive research background than I do, and I learned a lot about the research process from them. Repeatedly, I'd show the project scientist some heat plots I'd generated from the latest experiment, and he'd grill me: "But what does it mean?" And often, I'd reply, "I don't know. These are just the trends I'm observing." And we'd discuss things, and sometimes I would bang my head on the wall and say, "I don't know what to do from here," and he'd say, "That's research!" But eventually, some pathway would emerge -- collecting more data from a new experiment, analyzing the data in a different way, checking THOR to see if it was the source of any issues, and so on.
My takeaways:
Even as an undergraduate EE sophmore, I am capable of fulfilling the "electrical engineer" role, not just "electrical engineer underling"
Research is often about persistence -- if you sense there's light at the end of the tunnel, you have to find a way around the train
Small group, big company
CSIE consists of around 10 active members (slightly more over the summer because of visiting interns). By contrast, Cedars Sinai as a whole has over 1000 times as many employees as our little research group.
Because it was a small research group, I and my fellow interns had almost complete autonomy over our project. Our PIs and project scientists would suggest directions to go down in the group meetings, but design, troubleshooting, and analysis of results was largely in our hands.
Now, this may not sound like something new -- after all, basically every company I talked to at Caltech's career fair advertised giving interns "ownership over projects" and interns getting to "build things our company actually uses!" But I think the small group size really brought this to a new level. This wasn't a company or PI dusting a low-priority project off a shelf and handing it to an intern. For me, I literally took over the project that was on display when I first saw CSIE at the career fair, a project that my mentor had been actively working on for months. My work over the summer not only pushed that research forward, but also freed him to focus on...his many other projects! Because CSIE is so small that its founders are often working on several projects at once!
By contrast, the hospital itself is huge. During my orientation, I met all sorts of different people: nurses, specialists, technicians, administratorsm etc. While I was often locked away doing research far removed from the main hospital campus, every once in a while I'd get a reminder that I was part of something bigger: a visit from the head of all research at Cedars, seeing doctors and med students listen to the same seminar I'm listening too, and gathering for celebrations like the Wellness Fair.
It's a really unique size combination and I'm very happy I got to experience it.
Lab lunch on my last day of summer
Cedars volunteer dog...her badge has higher clearance than mine...
A scale model of someone's tumor that I got to keep as a souvenier
Medicine is interdisciplinary. It needs science and engineering.
And that includes science and engineering beyond pharmaceutical chemistry and biology, too!
Some things our lab does that I didn't realize hospitals needed until now:
Creating surveys to collect demographic information of patients
Creating models to help predict survival rate of a patient given their data and history
3D printing a dissasseble-able model of someone's tumor so our surgeon could visualize the different stages of surgery, and have a visual aid to present to the patient as he was explaining what he would do
Laser-cutting the director's face into a piece of wood (ok, maybe this wasn't *entirely* necessary...)
Not to mention all the research that has the potential to help future patients...
West Hollywood has good public transit?!
The bus comes every ten minutes and my route by bus isn't twice as long as by car? Sign me up! I was fortunate to have a car with me at my apartment, but I still opted to take the bus whenever I wasn't responsible for driving my coworker (co-intern?) to (1) save on gas (2) save on time eating breakfast and dinner.
Growing up in northern Arcadia, the nearest bus stop from home was over a mile away and my friends and I were not able to meet up at all without cars. By contrast, the bus system in west LA is truly incredible in that it gives you just as much, if not more, freedom as having a car. There are multiple bus stops on almost every block. The buses are coming all the time. And as a student, it's FREE! (Thanks, Caltech UPass!) Also, the buses tend to be safer than the Metro because of the presence of the bus driver. This experience has made me excited to try the bus system in Pasadena more...even if the buses only come every 20 minutes instead of 10.
image credit: Bus station in WeHo