Lincoln Randall McFarland

Location: Mountain View, CA 94043

Phone: (650) 967-5336

Email: Instructions found on starbug.com

Objective: To create great software applications, models and simulations.

Education: B.A., Physics, University of California at Berkeley, 1985.

Updated: 17 July 2008

Computer Experience

I am fluent in C/C++, Python, MySQL and Java and have a good working relationship with Unix shell scripts (Bourne and C shell families), Perl, Tcl/Tk, Expect, flex and bison, SWIG, and make. I also have worked with Fortran, Lisp and Scheme.

My experience is largely with the Unix family of operating systems (Linux, OSX, BSD, HPUX, Irix, Solaris). I have a similar, but less extensive, history with the XP, NT, W95, MS-DOS, and VMS operating systems, their applications, communications and supporting hardware.

Work Experience

At IronPort I lead the development of "the corpus", our database of spam, through its 2.0 release, for use with our anti-spam tool, IPAS (IronPort Anti Spam). After corpus 2.1, I lead the development of our DNS reputation server (SBRS) also taking it through its 2.0 release. For both products, I was responsible for writing the specs, code, user's guides and other documentation, coordinating the contributions from other engineers, working with QA to develop test tools and methodology and resolve the bugs that are found.

I started at IronPort as the new lead developer on the corpus for its 1.7 release. I created a set of daemons using python that processed incoming email from our traps by scanning it with several spam and virus products. After scanning, the results are parsed from the email headers and stored in a MySQL database. IPAS pulls a set of test email from the corpus for nightly scoring to determine an optimal set of rules to be pushed to our customer's IronPort mail servers. As the corpus progressed through its 2.0 release, I lead the development effort to hand off the maintenance and further development to our Ukrainian contractors. I wrote the functional specifications and the user's guides for new developers, QA engineers and system administrators.

My initial work on SBRS was to do the planned re-factoring and prepare the code base for a 2.0 release. I surveyed the code tree, pruned many dead branches (reducing the code line count by 60%), created the user's guides (increasing their line count by 1000%) and updated the configuration process to use our newest tools, while preserving the underlying data structures (mostly in the MySQL schema) to reduce risk. Once we were confident that the process was clearly understood, updating the data structure became the focus of the 2.0 release. I worked closely with QA and system administration to provide them with the tools they need to monitor the system and verify it is functioning correctly as well as provide documented procedures about what to do if it is not.

I implemented a new computational framework for atmospheric and surface remote sensing, called CSFSR (Classification of Spectral Features in the Solar Radiation), for the Information Physics Group. I also worked on extending the Signal Processing Environment for Application Development (SPEAD) tool kit for the Neuro Engineering Lab.

The CSFSR is a largely C++ test framework that was used to look for the optimal solution to the most likely mix of gasses (O3, O2, CO2, NO2 and H2O) seen in a high spectral resolution satellite image of the earths surface. It combined solar radiation data with HITRAN data about how these gasses absorb light in the atmosphere and used the standard Fortran program DISORT to analyze an image. We experimented with several techniques to find the optimal solution, including simulated annealing and gradient decent. I was responsible for implemented the application using equations provided by the physicists in the information group. I also created the C++ wrappers for the Fortran functions in DISORT to link them directly to CSFSR, eliminating the need to parse DISORT's normal text output and greatly increasing the speed of processing. I also built several test harnesses to validate the accuracy of the model.

The SPEAD tool kit is written using the Qt tool kit. I added several signal processing modules, including simulators of a simple sine wave signal generator and mixer along with a spectrum analyzer and oscilloscope. I also created a qmake file builder language along with a python script to process it for generating the makefiles needed by Qt to build SPEAD.

I joined the SETI Institute to work on Project Phoenix's Search System Executive (SSE) for the New Search System (NSS), the continuation of the NASA program to observe stars with in 200 light years for radio signals. I wrote many applications to support the observation, from the control interface to the telescopes through to the to the database to store the results.

I was off to a quick start by being able to built on experience with things I hand done in the past (see below, like using the GPIB bus (IEEE-488) to control RF equipment, e.g. tuning local oscillators, setting step attenuators and switches, generating test signals and monitoring system status. To simplify configuration and add flexibility and maintainability into how observations were programmed, I created a created a C++ library of the equipment (factory pattern) and wrapped this with SWIG to create a simple command interface. I turned this into a simple TCP/IP server by using Tcl's socket library to process strings sent to a socket. This allowed a client as simple as telnet to send commands to the server. This also made it easy to use Expect to create a suite of QA regression tests to validate the server. Security, of course, depended on access to the network.

I was also fortunate to have the opportunity to do many things I had not done before. Working mainly from the Rubini Linux Device Drivers book, I wrote the device drivers for two custom PCI boards used to process the signals and monitor status. I created the MySQL schema and the C++ and Java APIs to store the test input parameters and results of the observation, which included many thousands of signals, all RFI from things like ships radars and cell phones. I also created a Java SWING application to provide a GUI for the database to make it easier for the astronomers to access the data and generate reports.

However, the most fun was to participate in the observations with the astronomers at Arecibo and Jodrell Bank. I wrote a common interface to both of the observatory's telescope pointing controls and did a lot of on site setup and debugging of our hardware and software.

At Frequency Technology I worked on the Columbus product, a tool for creating a SPICE model of the parasitic capacitance in the interconnect circuits of integrated circuit designs. I developed several ports of the source code base from Solaris to HPUX and IRIX platforms updating the build infrastructure using Rogue Wave's implementation of the C++ STL.

I did research on how changes to the mathematics of the model would effect the results, creating several special purpose software tools to accomplish this. I wrote an C++ parser to allow Columbus to parse hierarchical SPICE decks and developed a command line option object to simplify setting and accessing configuration information. I also re-factored our Perl build scripts to support builds on the HPUX and IRIX platforms.

As a member of the multimedia group, I developed several modules, in C++, for our Signal Processing Workbench (SPW) product, a graphical tool kit for constructing models of signal processing systems. I also provided documentation and customer support for installing and running the new modules.

The modules were part of a custom model built for Fujitsu of their JSAT MPEG-2 decoder. These included interfaces to load video data to and from disk files, modules for mixing on screen display information into the video stream using the vertical blanking interval as well as modules to model an asynchronous serial bus and a IC card reader.

I wrote makefiles to build the source code generated by Rational Rose for the TrimTalk communication product.

At TIW, I developed the software (C++/Tcl on Unix) for our in-orbit test (IOT) system of satellite transponders. I was also responsible for installing and verifying the equipment at the customers facilities (in China, Italy, Luxembourg, Virginia and Wyoming).

The IOT consisted of a suite of tests, often customized to meet customer specific requirements, that measured the performance of a transponder once the satellite was in its working orbit. These tests ran on a Unix work station (HPUX and Linux) by sending commands over custom TCP/IP client-server applications and via the GPIB bus (IEEE-488), to signal generators. The return signal was measured with a spectrum analyzer or RF power meter and the results were stored in a relational database. I developed a C++ library for the instruments we used which allowed us to mix and match hardware to quickly address customer customizations. I also wrote the schema for the database tables.

The test were used on SES Astra's 1D, ChinaSat's DFH-3 and EchoStar's EchoStar1 satellites. They measured the satellite transponder's local oscillator, equivalent isotropically radiated power (EIRP), saturation curve, frequency response, G/T, spurious emissions, and inter-modulation characteristics to name a few.

I started at Lockheed running Fortran computer models of how unintentional signals get into electronic systems, e.g. electromagnetic compatibility (EMC). I developed C applications to first analyze the data and then extend the range of the models. I finished in the Algorithm Development Group developing a signal processing model to show the effect of various signal recover techniques.

My first job at Lockheed was to collect the data for and run a industry standard Fortran computer model (IEMCAP) of cable bundles in spacecraft designs with regard to electromagnetic compatibility (EMC), a.k.a. cross-talk. I used the results of these models to show our flight hardware met the MIL-STD-461 requirements or when it didn't, determine whether it was safe to grant a waver or not. I was also responsible for observing the hardware test in the EMC lab. Working with Tempest engineers, I developed a new application in C, based on a set of equations in an IEEE paper that would allow the model to calculate the cross talk at the much higher frequency requirements of Tempest.

In the Algorithm Development Group, I wrote the X11/Motif GUI for our signal processing tool kit (CWID). I also implemented many of signal processing algorithms. This application served as a test bed for developing new techniques in continuous wave applications, interference rejection, peak detection. After leaving LMSC, I continued to develop signal processing tools like the java applets on my web page (www.starbug.com. See DSP made simple and Make Waves with FFTs). I also received a lot of hands on experience with the signal generators, spectrum analyzers and oscilloscopes in our lab.

I was responsible for producing articles on various aspects of energy conservation in residential housing. This included researching the topic, interviewing people involved with the technology, writing the article and preparing the magazine for publication and distribution.

As the third employee, I was involved in setting things up for the first time, e.g. figuring out how to use nroff to do our type setting, building a database of subscribers and writing the excel macros to print labels for mass mailings. My articles on energy conservation included the advantages of compact fluorescent light bulbs and the results of calorimeter measurements I did on the efficiency microwave ovens to name two. I presented a paper on desk-top publishing at the 1986 ACEEE conference. I also worked as a teaching assistant for Energy and Resources Physics class at U.C. Berkeley.