I belive that a solid design should generally begin with an initial set of understandings before anything is executed. These include, in order:
Understanding the full overall system architecture
Realizing power delivery constraints and specifying power requirements with plenty of margin
Encouraging modularity so that each subsystem will be able to be individually tested, exercised, and replaced easily, while implementing safeties that will protect the board and anything upstream/downstream from transient effects
Finally, listing down specific requirements from internal and external teams and engineering a solution that fits the bill, given a variety of trade-offs
Aside from being the self-proclaimed "Head of the Board Naming Committee" at BD Biosciences, I am also a board designer and I have single-handedly ran schematic capture on several boards, while contributing to the requirements and architecture of others, as well as working to understand existing boards to carry out re-spins. I also lead the layout for these boards, supervising the layout engineers to perform best design practices and working cross-functionally to make sure all mechanical/FPGA/firmware requirements are met. At times, I have also been responsible for initial firmware development of my boards, to kick things off for testing to meet intense scheduling demands.
Outside of the design cycle, I am the integration lead, using my expertise in the system architecture and knowledge of board test, bring-up, and troubleshooting to package everything my team and I design together into the final unit that will ship to customers. I have performed the role for 2 such cycles and thoroughly enjoy the role and all the challenges that come with it.
Two Temperature Sensors
I have designed 2 temperature sensors in my time at BD. The first used the 1-wire protocol to communicate and satisfy our system requirement. This was facilitated to the host system through a USB transceiver. The second temperature sensor was a simple i2c sensor whose charm was in its size and scalability. It is a tiny board, able to be placed anywhere and scaled up to 16 iterations.
Two Power Distribution Boards
The instrument we produce consists of two chassis, referred to as the upper and the lower. I was responsible for designing the lower chassis power distribution board for the initial early access unit release of the instrument and both upper and lower chassis power distribution boards for the commercial release of the instrument. That's 3 power distribution boards. The design process was done as described above -- understanding the overall system architecture to know what subsystems require electrical power and budgeting just how much power they need, spec-ing out a power supply that fits that power budget, utilizing unique connectors for each subsystem that aren't interchangeable so that assemblers aren't able to accidentally miswire power connections, and laying them out in a compact package with connector placements that are in intuitive locations that are helpful to builders in the manufacturing plant. The upper power distribution board also included some signal distribution, such as an i2c mux to distribute the i2c bus throughout the upper chassis, relays that carried signals to shut lasers on and off for safety, and in-line common-mode choke filters to make sure all noise on power delivery was dampened.
LED Driver
The simplest of boards, yet not lacking in importance -- the LED driver board is positioned on the front panel of the machine and is able to drive 16 RGB LEDs in fluid and dynamic fashion via i2c. Aside from the computer software, this is what users rely on to see that status of the instrument in real time, as it displays different colors for different operation modes. The point of pride for this design is that it was designed to be able to be driven by two different types of LED drivers and during "The Great Semiconductor Shortage of 2020," that flexibility is what avoided a delay in production.
Motor Driver Interface
I designed a motor driver interface that would facilitate RS-485 communication between an X-axis and a Y-Axis motor controller module, while feeding back encoder position data to the main system. This board included an e-fuse for upstream/downstream electrical safety, hardware safety interlock implementation to halt motors if a user breach was found, and debug USB as an alternate method of troubleshooting, should RS-485 spaz out. Next steps that are in-progress for this design include insourcing the controller module to make it a fully internal design.
Temperature Controller
The temperature controller is a 6-port design meant to cool 6 modules using TECs for cooling and thermistors for feedback. The tight temperature regulation requirements for this board made it challenging... +/-0.05C. This was achieved by tweaking the control loop by playing with the location of the poles and zeros, adjusting the heating and cooling voltages and currents, and by working alongside mechanical engineering colleagues to make sure heat-sinking is being done properly and conditions are conducive to cooling at a tight regulation range, unprecedented at the company before. This design included a microcontroller that took in the thermistor measurements into its ADCs to report back to the main system, delivered a user-defined setpoint to the temperature controllers, monitored for overtemperature/undertemperature alarms, and communicated its ADC measurements to an external computer for onboard self-testing via i2c.
PMT/PD/APD Driver Boards
I worked alongside a world-class, expert analog engineer to capture on schematic his patented method for driving PMTs, PDs, and APDs, and sending that analog data differentially to an analog front-end board with minimal noise injection and maximum bandwidth and dynamic range.
Bring-up, Testing and Integration
While the bulk of my job is working on designing the boards mentioned on this page, outside of the design cycles, I am the Integration Lead and I work on conglomerating all (~20) of the boards into the system and working cross-functionally to debug integration issues that inevitably arise, troubleshoot failures to evaluate if redesigns are needed on subsystems, and make sure those subsystems are working together harmoniously. In the margin of time between the design cycles and integration, I also characterize exhaustive tests that need to be performed on my boards for bring-up purposes.
Technical Skills
In addition to board design, I have also been trained on certain technical skills to facilitate board/system operations, such as soldering for rework and creating cables in our internal shop that we use in order to operate the boards and let them communicate with each other.
I was in charge of re-spinning the upper chassis controller board, which included swaps on FPGA lines, correction of various signal names and functions, pull-up/pull-down add-ons, replacement of certain bi-directional level shifters, and replacement of certain RS-232 transceivers to RS-485.
Relative Location Tracking
My main project at NASA was to provide a proof of concept for 1-to-1 relative location tracking so that satellites can use it to communicate their locations to each other because GPS doesn't exist in space. Currently, objects only know the locations of other objects either by GPS triangulation or by RSSI. RSSI only provides the separation distance, but not the orientation or direction data point. The system and process my team and I developed, which we later moved on to our university as our senior design project, was able to successfully calculate the relative distance and direction of an RF source, plot it on a polar graph, and display to the user, with precision, where a relative RF source is located.
Outer Space Greenhouse
This project was basically a ferris wheel for plants. We placed different plants in a ferris wheel that we created and controlled through a microcontroller board. We then ran the ferris wheel at different speeds to simulate gravity in other planets' surfaces and monitored the plants' growth in order to characterize how they would grow differently.