Shipped Product

Rylo Camera

Who: Rylo
When: 9/2016-4/2017
Where: San Francisco, CA
Languages: C++, CMake, Groovy, Jenkins Pipeline

We supported Rylo's first product development effort with the following services:

  • Schematic review
  • Build system & build server setup
  • Creation of product development roadmap & schedule
  • Creation of manufacturing test plan
  • Managed multiple external vendors
  • Build support in China
  • Bring-up of manufacturing test firmware
  • Bring-up of customer camera firmware behavior

RearVision

Who: Pearl Automation
When: 2014-2016
Where: Scotts Valley, CA
Languages: C, C++, ARM assembly, Thrift, Python

Pearl's RearVision consists of two separate embedded devices - the camera system, mounted on the car's license plate, as well as an in-car OBD-II powered system.

Phillip was an early hire at Pearl - #12, hired right after series A closed. He was the primary developer for the camera system.

In the early stages of the company, Phillip performed initial bringup of the system and was responsible for:

  • SOC Bringup
  • RTOS Selection
  • Setting up the build system
  • Porting initial software from gcc to clang
  • Software / source tree architecture
  • Implementing the DFU framework to flash devices
  • Creating a USB CDC shell and defining commands for various drivers
  • Driver bringup for multiple devices
    • SPI
    • SPI-NOR
    • Solar IC
    • GasGauge
    • USB
    • EHCI (ported u-boot EHCI stack to our system)
    • Cameras
  • Defining factory test methods and processes

After the bringup stage, focus shifted to firmware support for the camera sub-system. Responsibilities included:

  • Implementing low-level C++ functionality in the RearVision frame firmware
  • Converting early libraries and drivers to C++
  • Conversion of C-based USB Host stack to C++
  • Ported vendor host-side Camera USB/UVC APIs from Linux to an RTOS
  • Managed interfaces for client software to initiate and configure video streams.
  • Worked closely with our ISP vendor to:
    • Identify and prioritize requirements and issues
    • Assist in debugging ISP, video, and memory issues
    • Optimize ISP pipeline performance to reduce latency and improve quality over BT/Wifi
  • Optimized video system memory usage
    • Created a buffer pool class to re-use large buffers in camera path
    • Eliminated all copies from USB->Camera path when getting new frames.
    • Converting malloc()/free() calls to use smart pointers
    • Debugging memory stompers

Further Reading:
PearlAuto Website

iPhone 6 & 6+

Who: Apple
When: 2013-2014
Where: Cupertino, CA; Shenzhen, CN
Languages: C, Lua

After the iPhone 5C, Phillip transitioned onto bringup for the iPhone 6/6+. A shortage of team members meant that Phillip managed both the iPhone 6 and iPhone 6+ projects. After EVT was completed, he transitioned to project management of the iPhone test lines. He traveled to most builds for both programs during this product cycle.

Factory SW:
During the prototype phase, Phillip was responsible for rapid bringup of new drivers for evaluating parts at prototype builds. He worked closely with the product development and reliability teams to make sure they had the ability to validate all the parts under consideration while at the builds. He also expanded our driver and factory test support to encompass new design changes.

Phillip spent significant time training and developing the CM software team. Unlike on the iPhone 5C, he managed to get the iPhone 6 CM team to help write software, allowing the firmware team to manage their immense workload by offloading tasks to the CM team. Phillip's strategy was to keep the hardest tasks for himself - once a task could be crystallized into a simple set of instructions, he would utilize the CM team. This allowed him to stay ahead of deadlines with an extremely challenging schedule, and helped to expand his communication and project management abilities. It is not simple to provide instructions across language barriers!

Current testing was expanded on the iPhone 6/6+ programs. Limits could now be set for different phones while keeping the same core software logic (previously, duplicate software was required). Also, much of the current testing coverage was pushed up to SMT to catch failures before final assembly.

Factory PM:
After transitioning to project management, Phillip's primary responsibility was the factory test and calibration lines. He was responsible for coordinating software and fixture readiness, ensuring that software, fixtures, and other critical deliverables were ready for each builds. He frequently briefed executives on program status and readiness for hardware builds.

Phillip became well-versed in crisis management, as there were always new failures, missing coverage, late deliverables, and missing support. Prioritization and triage were important in making sure build goals were met without further delays.

Phillip managed test plans, test coverage, and line flow for iPhone 6 and iPhone 6+ development, including these areas:

  • SMT
  • Subassembly
  • IQC
  • FATP
  • Rel
  • Packout

iPhone 5C

Who: Apple
When: 2013
Where: Cupertino, CA; Shanghai, CN
Languages: C, lua

The iPhone 5C was Phillip's first project at Apple. Phillip joined during the EVT stage of the project, and his primary focus was expanding test coverage, debugging failures, fixing issues, and driving down retest rates and cycle time. He traveled to each remaining development build until the product ramped (4 builds).

Prior to the development builds, Phillip worked with with a variety of external teams to drive and implement test requirements:

  • System HW
  • RF HW
  • Touch firmware/test
  • Sensor HW
  • Operations
  • Reliability

During a late-stage part switch, Phillip performed a rapid bringup of a new accelerometer - this was a high pressure situation, as the build material was being held until firmware support was completed.

At development builds, Phillip worked closely with the Apple System HW team to debug failing units. Together, they worked to distinguish hardware failures from software bugs and add new coverage to catch failures that were missed.

Phillip joined forces with the System HW and RF HW teams to expand the current testing suite run during burnin. This testing suite helped identify numerous software bugs, SMT issues, and caught a major reliability issue prior to MP. The success of current testing on this product resulted its expansion and use at SMT in later iPhone products.

Phillip also worked closely with the operations team to monitor retest rates and test cycle times, helping improve UPH on key test items.

Phillip taught the CM's software team to help triage and debug manufacturing test issues. During later iPhone builds, failure and retest quantities become too large for one person to filter through. Developing the skills of the CM software team helped the firmware team stay afloat and focus on new issues rather than duplicates.

I-BESS

Who: Georgia Tech Research Institute (GTRI)
When: 2010-2011
Where: Atlanta, GA; Charleston, SC; Aberdeen, MD
Languages: C, ASM

The I-BESS project was sponsored by the U.S. Army Rapid Equipping Force (REF). I-BESS was developed to collect data on the effect of IED blasts on a soldier. Many soldiers were coming back from Iraq and Afghanistan with traumatic brain injuries (TBI) and the Army needed data to understand how soldiers were being injured.

The I-BESS system consisted of four parts: a soldier body unit (SBU), a vehicle unit mounted to the back of each seat (VIA), a headset, and a black box recorder which stored the data inside each vehicle. The SBU and headset were designed to collect directionality, pressure, force, and head rotation that a soldier experienced during an IED event.

Phillip was the lead developer for the VIA system. The VIA system utilized bluetooth, wifi, RFID, and CAN to communicate with the other products in the ecosystem. It also included a high-g accelerometer to measure force during an IED event. When a soldier sat in a seat, the VIA would exchange wifi connection information over RFID, download the stored event data, and send the data to the black box computer. Both the VIA and black box recorder collected their own IMU data during IED events involving the vehicle.

In the early stages Phillip was responsible for bringup of the new design, working closely with the HW and RF teams to debug issues. One of the key parts - the RFID controller - had very poor documentation from TI, and the RF group was undergoing restructuring. Phillip reverse engineered the communication protocol using example binaries provided from TI and produced an Interface Control Document (ICD) for the part.

The project involved frequent travel to the SPAWAR facility in Charleston, SC to perform various tests: fit check, radio jamming, installation, in-vehicle performance. During later stages of the project, the travel shifted to the U.S. Army proving grounds in Aberdeen, MD, where live demolition tests were performed.

System Architecture

ref_arch.png

VIA System

via.jpg.png

Future Airborne Capability Environment (FACE)

Who: Georgia Tech Research Institute (GTRI)
When: 2010
Where: Atlanta, GA
Skills Developed: Research, Documentation, API Design

The Future Airborne Capability Environment (FACE) project was started by the U.S. Navy. The stated goal was to produce a common software architecture that contractors would adhere to. Software projects would be decoupled from the hardware interfaces, allowing the U.S. government to accept competitive bids from multiple software developers. The status quo is/was to be locked into a single vendor due to complaints about opening up their own intellectual property.

When the FACE was being formed, GTRI was tasked with working in parallel to the committee to come up with an alternative common architecture proposal. While working on this team, Phillip's role was to perform research on API design, military architecture challenges, military hardware, and software architecture. These findings fed into a section of the original GTRI FACE proposal.

GTRI later worked with the FACE consortium to develop the final standard and proof-of-concept software implementations.

Further Reading:
Wikipedia summary
OpenGroup: Future Airborne Capability Environment
Five Reasons FACE is Succeeding as a Global Military Standard

MIL-STD-1553B Bus Analyzer

Who: Georgia Tech Research Institute (GTRI)
When: 2009-2010
Where: Atlanta, GA
Languages: C, Visual C++

Phillip's major software development experience was working on a MIL-STD-1553B bus analyzer. The software supported monitoring, recording, playback, and decoding messages sent to EW/avionics systems. This software had been written and maintained by GTRI for 10-20 years, leading to a large and unruly code base.

Phillip supported a major release cycle and was responsible for a variety of activities:

  • Integrating support for decoding traffic on new systems
  • Incorporating new interface updates for supported systems
  • Fixing bugs identified in previous releases
  • Reviewing formal software test plan, fixing errors, and incorporating requirements for new feature sets
  • Running formal software tests prior to releasing the software to the customer