Hi! I'm a senior Electrical Engineering major at the University of Texas, graduating in May of 2019. Here are a few interesting projects that I've worked on! Fair warning: there's a good chance at least some of this stuff is hilariously out of date.
Longhorn Racing Electric is a 3 year old Formula SAE team at UT Austin, competing every summer at Formula SAE Electric in Lincoln, Nebraska.
As the team's electrical lead, I am responsible for the design and construction of the car's high and low voltage electrical systems. I designed the overall architecture of the 2017, 2018 and (upcoming) 2019 car's control systems, and personally worked on the electrical design of the car's battery pack and battery management system (BMS), as well as the team's custom developed vehicle simulation software.
The 2018 vehicle's battery pack is constructed from 720 18650-sized lithium-ion cells in a 72s10p arrangement, for a maximum pack voltage of 302.4V and 6.3 kWh of capacity. The cells are divided into "segments" and are spot welded together with sections of 0.005" nickel sheet sandwiched between thin aluminum plates to provide extra current capacity. The pack is capable of delivering current in excess of 200 A.
Each of 6 12s10p "segments" has a set of BMS slave PCBs, each with a single LTC6804 battery monitor IC connected to the segments' voltage taps, as well as 60 multiplexed temperature sensors. Each segment is designed to be removable from the pack for maintenance. All connections, including voltage and temperature sense, are integrated into the PCBs, and the segment PCBs are powered by the cells they measure, meaning there is no wiring on the segments except a single twisted pair for communication with the master via isoSPI.
The control system consists of a front and rear microcontroller node connected to sensors such as pedals, dashboard buttons, and temperature sensors, as well as a smart power distribution board. All three boards use Texas Instruments TM4C microcontrollers and communicate on a single shared CAN bus. A BeagleBone embedded computer also hangs off the bus, and is connected to a WiFi router to give us features such as a webserver providing real time telemetry, datalogging, and the ability to remotely reflash microcontroller boards via an embedded CAN bus bootloader. I wrote the majority of the embedded C code onboard the car and contributed to the core structure of the BeagleBone setup.
As a member of the Longhorn Rocketry Association engine development team , I was in charge of the electronics and software for our first engine test stand. The test stand is powered by a 24V battery for portability, and the controller features 11 analog transducer inputs, 5 K-type thermocouple inputs, and 10 outputs for 24V solenoids.
I designed the test stand controller around TI's TM4C ARM-based microcontroller platform. The first version of the controller is a breakout PCB which plugs into a TM4C1294 "LaunchPad" evaluation board, and connects to the control computer over Ethernet. The board interfaces with pressure transducers (or any 0-5V analog sensor) through a 16-bit, 200ksps ADC behind a 16 channel analog mux. The thermocouple inputs use the MAX31855 thermocouple ADC, connected to an SPI port on the microcontroller. The PCB also features a MicroSD card slot to log data faster than it can be sent through the microcontroller's fairly wimpy TCP/IP stack.
The electronics box for the test stand also includes a wireless router to connect to ethernet IP cameras on the stand, as well as connecting wirelessly to a GoPro camera, using a custom LabVIEW library to remotely trigger and monitor the GoPro.
The stand controller interfaces with the control computer by sending and receiving UDP packets over Ethernet to a LabVIEW application. I made the decision to keep as much of the code as possible on the LabVIEW side, so it would be more easily accessible to other LRA members, who are mostly aerospace engineering students. The LabVIEW app controls the timing and sequencing of stand operations. It reads in a test sequence from an Excel spreadsheet, monitors sensor data for "out-of-bounds" values, and automatically executes different sequences in response to fault conditions. The end goal of the software is for anyone in LRA to be able to design, set up and run their own engine test sequence without modifying the code.
This project was a part of the EE X60 program at UT, which is an independent research course for class credit.
For my project, I developed a platform based on the TI MSP432 low-power microcontroller to be used for research on software algorithms for hearing aids. I made a PCB to plug into the MSP432 LaunchPad, featuring three different microphones for evaluation, along with a DAC and headphone amplifier. The idea is to power the device from a USB battery bank, and listen to processed sound using noise-cancelling headphones.
I chose three different Adafruit microphone breakout boards to evaluate, including two electret microphones and a MEMS microphone. The three microphones are connected on-board ADC ports on the MSP432, which processes the signals from a chosen microphone and outputs processed sound via a 14-bit DAC connected to a LM4808 headphone amplifier. While the MEMS microphone required external amplification and filtering, it proved to be the most robust of the three options due to its .... However, the MEMS microphone is particulary susceptible to high-frequency sound outside the audible range.
One of the software components for the project was an input filter. I wrote a MATLAB script to generate FIR (finite impulse response) filter coefficients for a desired frequency response curve. After plotting the desired transfer function magnitude of the filter in the frequency domain, performing the inverse Fourier transform of the transfer function the filter tap coefficients of the filter. FIR filters are particularly suited for this application, because they can be implemented as a series of fixed-point multiply-accumulate operations, and can be designed to have a linear phase response, minimizing audio phase distortion.
Stuff in Space is a realtime 3D visualisation of the over 15,000 tracked objects in Earth orbit, which I built during the summer after graduating from high school.
The application itself is divided into 3 parts. The main page responds to UI events, performs a linear interpolation of satellite positions in between updates, and does all of the actual WebGL drawing. One background worker receives a copy of the trajectory data, and calculates a new position and velocity for every object every 500 ms, posting the updated position and velocity vectors back to the main page. A second background worker is used to render the orbit paths that appear when the user selects an object or a group. It maintains a "work queue" of orbits to render or update. When given a new set of orbits, it calculates the object's position at 256 future points and posts its results back to the main page.
I made this 4x4x4 RGB LED cube as a side project during the fall of 2015 to learn more about PCB design, after finding out I could make 5 of these PCBs for only $12 online (if I was willing to wait a month for shipping from China). It uses three 16-channel TLC5940 LED drivers to PWM a single layer of LEDs at a time. Four p-channel MOSFETs provide a "bank-switching" function, allowing each layer to be turned on or off. Rapidly cycling through the four layers of the cube creates the illusion of control of individual LEDs.
I 3d-printed an alignment jig to solder each layer of LEDs together separately. The R, G, and B leads of each LED are stacked vertically, while the common cathode is connected sideways to the other cathodes of the LED's layer.
The fully assembled cube before trimming the leads. It's controlled by a sketchy Ebay Arduino Nano clone, and can connect via USB or UART to a computer to react to things like email notifications or weather conditions.
The first custom part I made was an RGB LED controller. It's based on an AVR microcontroller using 6 PWM outputs to control 2 pairs of RGB LEDs. I also added an audible indicator that warns when the quadcopter is armed and when the battery is low, using piezo speakers taken from old computers, driven by a 555 oscillator circuit. The board communicates with the main flight controller, receiving status data to update the LEDs and drive the buzzers based on the measured battery level and status of the R/C receiver.
The flight controller board did not have enough usable digital IO pins, so I built a board to convert 8 PWM channels from the R/C receiver into one PPM channel that could carry all of the R/C data on one digital pin. This freed up 7 digital IO pins for other uses.
I used a cheap serial telemetry module to connect the quadcopter to an Android tablet-based ground station that could display live data from the quadcopter. An app on the tablet displayed and logged live telemetry data.