I have a lot of work experience, as a consultant and as a full-time employee. This is a list of the significant projects I’ve contributed to.
Table of contents
October 2010 – Present, San Jose, CA
Lead the effort to take our discrete force implementation from a single-customer code base, to a platform code base. This required looking beyond individual customer needs, and generalizing the firmware design to support different sensor designs and tuning requirements.
I refined, debugged, and documented an API that allowed customers to develop their own firmware running on Synaptics’ ASICs, and developed test cases to verify the API worked as intended.
Debugging has always been complicated on Synaptics’ ASICs. I implemented the firmware side of a debugging capability that provided improved debugging tools for other firmware developers. This firmware integrated with an Eclipse IDE, through an I2C (RMI) interface.
I architected new firmware for a capacitive sensing keyboard. This required new algorithms and integration with new hardware. This allowed us to detect touch and press. Leading a small team from Taiwan, India, and San Jose, we delivered this, on time, to support various demonstrations at electronics shows and for customers. This required travel to Taiwan and China to support potential customers and production teams.
Resolved various customer problems as part of the Human Interface product group. This group concentrates primarily on capacitive Touchpads, STYKs, and other human input devices.
September 2009 – October 2010 San Jose, CA
This contract brought me to northern California. I was part of a small team that developed the hardware and embedded software for Sunpower’s monitoring system, used to track the energy pmonthsroduce in the solar panel systems. This system collected data from inverters and remote servers, shared data between units with a proprietary RF protocol, and uploaded data to company servers. Units consisted of an 8051-based display running an interrupt-driven scheduler and a logger and gateway that were ARM-based systems running uC/OS. All units were developed with IAR Embedded Workbench.
The original design was having various problems, so we designed and built a replacement system that used Linux and Busybox, running on a hardware system from Moxa. I helped define the requirements and implement the features in C/C++ and Perl (as part of a browser-based reporting and configuration page), and verified the system.
July 2009 – January 2010, Irvine, CA
This was a side project for a remote control for studio equipment.This was a fixed-price contract, so I defined the scope and requirements so it was clear what was needed, and test cases that, when passed, would deem the project complete.
It was done in two phases: the first was a TI MSP430-based board that detected switch presses, accurately measured revolutions on an optical encoder wheel, and various other tasks, all using an interrupt-driven scheduler. The second phase integrated this with a Linux-based system that communicated with the MSP430 through a serial interface. The MSP430 has the ability to update the application through the bootloader. When this was integrated into the Linux system, I wrote a Linux application was needed to send a local image to the MSP430 through a serial interface.
There was a problem integrating the two systems, and rather than pointing fingers at the other team, I flew to their site to debug and integrate the two components (the main problem being device permissions in Linux). We then had problems with new MSP430 boards that the firmware didn’t seem to work on. I was able to troubleshoot this and determine the problem was improperly sized resistors that prevented the GPIO from responding properly, preventing the firmware from detecting encoder wheel motion.
May 2009 – June 2009, Pasadena, CA
This was a short-term consulting gig to help setup and demonstrate an RFID loss control system. I helped define the system needs, the interfaces between various programs, and helped integrate the individual components into a working system.
I wrote a C++ program, that used the LLRP library, to communicate with an RFID reader from Impinj. This information was shared with a C# program that queried and updated an SQL database with the found RFID tags. A GUI used the database to display information about what tags were found and which went missing.
March 2008 – November 2008, Burbank, CA
I was a firmware developer that helped Crane to meet its Safety-of-Flight delivery for the 787 Dreamliner braking system. This was a pretty cookie-cutter job, where I couldn’t use my system-level skills. The requirements were fed to the developers by a systems group, with very little ability to provide feedback and improve the algorithms developed. Nevertheless, I did try, and I was able to get clarifications on handling error conditions (which were often unaddressed), and provide some improvement to the provided algorithms. My efforts often seemed unappreciated, maybe because the schedule didn’t allow time for feedback.
Tools included TI’s Code Composer/Debugger for a TI TMS320F2812 DSP and Green Hills Multi for a Freescale MPC565 microcontroller. I verified functionality on a Triakis-based simulator and on the actual braking hardware. Working on an actual braking system was pretty cool; these are powerful mechanical devices around which you had to be careful for your safety and the braking system. We used Synergy CMS to track software and documentation changes.
G4S Justice Services
January 2005 – December 2007, Rancho Santa Margarita, CA
This division of G4S specialized in selling house arrest systems to various government agencies. It consisted of a bracelet that was attached to the person’s wrist or ankle, and a base station, that contacted a server via a POTS phone line. The bracelet periodically transmitted data to the base station to determine when the person was within range of the base unit. When the bracelet went in or out of range of the base station, the event was logged, which the base station transmitted to a server. Later, a GPS unit was added to the system to track people that moved away from the base station.
I was the main developer for the bracelet. It was battery operated, so power consumption was a primary concern. It was also imperative that the radio communications work flawlessly, while still supporting other functions like audio feedback and battery and signal strength monitoring. To prevent spoofing the presence of the bracelet by playback of a recorded message, the system used a modified version of the Tiny Encryption Algorithm (TEA) to encrypt the RF traffic. The bracelet used a TI MSP430 microcontroller and a Semtech RF1203 UHF transceiver.
I also redesigned and implemented a new communication interface on the base station. Since RF timing had to be precise, the base station used a TI MSP430 to control the RF, and an M16C to control other operations, like the modem, LCD display, etc. The problem was that the communication between the two processors could be delayed due to the M16C’s other tasks (especially the modem; the fw wasn’t designed to handle the long delays that could result from modem connections), and that would prevent the MSP430 from responding to the RF traffic in the time needed. The new design used used a state machine on both sides. If either side wasn’t immediately ready to respond, they firmware went on to other tasks, and came back later to see if communication could continue; neither processor was ever stuck waiting for the other. This eliminated the corrupted RF packets we often saw between the base station and the bracelet.
University of California – Irvine
August 2000 – June 2007, Irvine, CA
I defined the curriculum, and taught, an embedded systems programming class. Lessons used an Atmel AVR board (STK500/502) allowing students to get hands-on experience working with LEDs, D/As and A/Ds, serial interfaces (RS-232, SPI and I2C), and an LCD. I covered limitations of embedded systems, embedded considerations such as endianness, shared data problems, task switching and interrupts, the build process, and debugging methods.
July 2004 – November 2004, Irvine, CA
August 2000 – November 2002, Irvine, CA
I worked for Thales at two different intervals, which I think speaks to their level of satisfaction with my efforts. The first time I became the lead developer on one of the LRUs (line-replaceable units), the Audio-video controller (AVC). This included the typical lead roles of planning the tasks, interfacing with management and team members, and finding solutions to technical problems. I worked closely with the electronic hardware designer to bring up the board. The board ran a Linux OS on a Power PC-based board. Also implemented Linux applications that ran on the AVC, and created HTML pages that used CGI to display dynamic data.
On my second tour, I worked to deliver a hand-held controller for their In Flight Entertainment (IFE) system, which ran Linux on an ARM-based board. I created the root-file system (RFS), using Busybox. When we needed capabilities beyond what was available in Busybox, we cross-compiled the applications from source. I wrote bash scripts and makefiles to simplify rebuilding the system (bootloader, kernel, RFS and applications) simpler.
I also helped developed a Qt-based graphical application to demonstrate the functionality of the hardware, including the OLED display. I ported applications written for an x86 processor to this ARM-based system. Differences between the ARM and x86 architectures caused various errors that needed to be tracked down.
DRS Sensor Systems
October 2003 – July 2004, Torrance, CA
I joined a group that was taking an imaging system for other military vehicles, and updating it to work on an M1A1 tank. This system used a TMS320 DSP and relied heavily on serial communications.
The existing requirements were poorly defined, and my first step was to determine what the system needed to do, and determining how to test it. As expected, errors were found as part of this review, but there was resistance to changing something that “works”. We did go forward with the changes, and with a defined set of requirements and better tests, we were confident the system really did work, and a better defined interface.
I also spent some time proposing and implementing debugging tools, such as logging capabilities and additional error checking. to find problems earlier. This identified subtle problems like task overruns and communication errors, which allowed us to significantly improve the code.
I worked closely with the hardware design group to improve the FPGA logic that buffered serial communication. This allowed meeting real-time deadlines by reducing the interrupt overhead on the software design.
Innovative Media Systems
March 2003 – October 2003, Anaheim, CA
IMS was focused on providing an easy way help commercial aircraft to wireless sync data between the plane and a server when at the gate, using a GSM connection. The LRU was called a Terminal Cellular Bridge (TCB), which used a Linux-based system with various applications. The initial 2.4 kernel was a desktop system. I pushed for moving to an embedded Linux OS, preferably a Busybox-based system, but the decision was to stick with the current OS, and streamline it to a more workable size. I helped optimize this system, reducing the size of the kernel and RFS, and increasing performance. The RFS was compressed and stored as a RAM disk image to further reduce Flash use.
I needed to add external flash with an I2C interface. Unfortunately, the supplier of the processor board had no useful documentation in how to add hardware. I found the datasheet for the Super I/O chip, which the processor used for GPIO, and was able to determine how to configure and control two of these pins. I then updated the Linux bit-bang I2C driver to use these pins for accessing the flash.
At the application level, wrote HTML pages and Java applets to provide a graphical interface for updating the TCB software, and an application that made a GSM connection and initiated a data transfer when the aircraft landed. Used C and C++ to write an application that monitored system conditions, and used XML RPC to send and receive data to other system components.
November 1998 – August 2000, Anaheim, CA
This was my first consulting job. I realized that whatever history I had at Sundstrand, here, I was a stranger. Was I honest about my abilities, was I able to work in this new team, which had some interesting personalities. After a while, I became established and a key part of the team. This may have lead to a full-time job, but I felt the environment wasn’t a good fit for me.
My primary task was to develop software for the AMP and SERPOS systems for a new Navy submarine. Much of the documentation was done after the development, and I helped review the existing code and document it. Not surprisingly, this review of the code led to the discovery of problems. There was resistance to fixing these as “it works”, but of course, it really didn’t work in all of the required circumstances. I was able to push for correcting these problems. These systems used 4 Texas Instruments TMS320C40 DSPs. Software was developed using TI’s Code Composer simulator and emulator tools.
Hamilton Sundstrand Corporation
January 1988 – November 1998, Rockford, IL
This was my first job out of college. I worked at Sundstrand (later to be Hamilton Sundstrand) for over 10 years, and really enjoyed my time there. It had good engineers, generally good management, and gave me an opportunity to draw both as a developer, customer interface, and project lead. Unfortunately, my last project was one Sundstrand acquired from another company. That project was in constant crisis, and with some changes in management, whose only experience with me was this crisis project, convinced me to consider another path. Since I was currently working in southern California, I decided to relocate there and do consulting.
My last assignment was to lead 20+ engineers in the development of a power system for the Global Express business jet. This included scheduling, tracking progress, and directing the team’s day-to-day efforts. I defined the processes to be used for development and verification activities to meet DO-178B Level A requirements, and reviewed produced products (test requirements, specifications, etc.) for technical completeness and accuracy. Worked with, and presented to, the customer and certifying authorities to verify compliance.