Mark H. Patten
Electrical Engineer/
Embedded Programmer
Hello, I'm Mark Patten, an electrical engineer and embedded programmer.
I've been fortunate in my career to have been able to work on a wide variety of engineering projects, in many different work environments. I have performed all phases of electronic product development---conceptualization, requirements specification, electrical design, embedded programming, testing, verification, and product field validation. Much of my work has been in the RF communications, DSP, and antenna array processing area. This includes such areas as creating algorithms and embedded code for performing modulation/demodulation, filtering, forward error correction, direction finding, interference cancellation, and geoloction. I enjoy algorithm intensive programming---I have a good mathematical aptitude and try to understand how math relates to an actual physical process.
For many of the positions I have held, much of the code development has been less algorithmic and more routine maintenance of a codebase. I also have worked as a software lead, coordinating several developers working to maintain and improve code embedded in a released product, in response to issues raised by product users.
I've worked for large defense contractors with tens of thousands of employees, and also small niche companies with a dozen colleagues---I enjoy the challenges of both environments.
Born and raised in the Washington, D.C. area, many of my assignments have been in the Maryland/DC/Virginia area, and Washington will always be my home. But more recently, in the post-Covid world, I have accepted positions more widely---Huntsville AL, Rochester NY, and Detroit MI have been recent on-site assignments. It's been interesting to experience different locations and meet people from all over the country.
Skills, Experience, & Capabilities
This is a summary of what I've worked on over my career, categorized by job function. I hope it gives an idea of my capabilities. I have worked in many different types of positions, and I've enjoyed the particular challenges of each. And this is not necessarily the extent of what I see myself doing in the future: I am always learning and growing. I believe I have capabilities that apply to many engineering fields, and I hope that someday I get a chance to do them.
I have a wide range of code development experience. Much of my work has been at large companies, typically defense contractors, in a team with other software developers, working on software for individual components of large systems:
I maintained a codebase, responding to software issues tracked by tools such as Jira and VIPER. I merged our software changes and updated software repositories using version control tools such as Git, Bitbucket, and SVN. At my most recent position, I served as team leader---I coordinated software releases, getting corporate approvals from Quality Assurance groups, and meeting contract requirements for software releases (such as software scans). I've used Agile Scrum methodology at many of these positions, with which I found helpful (but I have no passionate feelings of either love or hate towards Agile, as do many of my colleagues!).
I also have worked for some very small companies:
The challenges of a small company are quite different from a large corporation, and working to meet those challenges has made me a more rounded engineer, I believe. At many of these smaller companies, I have developed from scratch, on my own, complete large embedded codebases for new products under development. These products typically would consist of a microcontroller or microprocessor interfacing to many devices, such as displays, buttons, Ethernet, CAN, and other hardware. The codebase performing all the software control for the product typically would be tens of thousands of lines.
I have worked through all phases of software development: requirements specification, software design, coding, implementation, and testing. Being involved in all development phases was much the case at smaller positions---Tektron and Frasier Optics in particular. At these companies I was usually either the sole engineer or the primary engineer, and was responsible for bringing electronic systems from concepts to real products.
I am fully fluent in C and C++, having been coding in both of them for my entire career.
Many of the codebases I have worked on make extensive use of C and C++ language features, such as structures and function pointers to improve code maintainability. For example, a codebase that implements "alarms"---things that happen for which the software need to take action---could just have a code section that checks for all the alarm conditions. But a more structured way to implement this is by setting up an array of pointers to functions, where each function defines when a particular alarm is active or inactive, and the program executes each function in the array to check for alarm conditions. This allows for greater flexibility for defining what can cause an alarm and makes it easy to add new alarms to the program structure by creating new alarm functions.
I make good use of structured programming, implementing conceptual programming structures (using state machines for example) when possible, to help make the structure of the program code match its function. I know how to employ efficient programming practices to maximize program speed and efficiency. An example would be sorting a large array by using an index array instead of ineffeciently swapping values in memory. Another example would be taking advantage of parallel instructions available on various DSP processors for highly repetitive operations like multiply and accumulate that are used frequently in things like digital filters. Many of the programs I have worked on are mathematically intensive, and I am acquanted with standardized libraries like IMSL and GNU Scientific Library for performing mathematical operations such as matrix inversion, polynomial root finding, matrix inversion, etc.
I have experience with most operating systems, including VxWorks, Embedded Linux, GNU, and Windows. Many of the systems for which I have developed have extensive contention for system resourses (such as memory), which is managed by use of the operating system functions. But many of the systems I have programmed have real-time processing requirements---they need to keep up with incoming data, like a digital radio that needs to process the signal as it is received. Frequently, these real-time systems are without operating system ("bare metal") to optimize program speed.
I have experience with many different processors. Much of my development has been for real time systems using DSP processors---at Raytheon, I used the Texas Instruments TMS320 processors extensively, and understand its features like chip architecture and parallel instructions. I've used ARM based processors (primarily Cortex M4) in designs at some positions---Digital Global Systems and Tektron in particular. Most of my designs at Tekton incorporated the Microchip "PIC" line of microcontrollers. At General Dynamics Land Systems, I gained insight into vehicle electronics design, and used Infineon TriCore processors which support vehicle interfaces such as CAN and are more immune to noisy vehicle environments.
Although I am reluctant to bill myself as a full fledged Hardware Designer, I would like to mention that I have FPGA abilities---I've created designs for devices by Altera (Cyclone III) and Xilinx. I have experience with the design software packages for each (Quartus, Vivado). Mainly, my designs have been created using schematic capture (i.e., block diagram using primitive function blocks) but I know Verilog and VHDL and in cases used it to define block operation. I would like to develop more experience with multicore processors and system-on-a-chip SoC) designs---I studied the Xilinx Zynq for a design, which contains FPGA and ARM, but ultimately used discrete components for each function.
Much of my work is straight software development, but I have a great interest in mathematics, digital signal processing (DSP), and software algorithms. At several positions, I performed algorithm development work:
My geolocation experience falls into two types of systems: One is an array of antennas spaced relatively close together, and processing the phase differences between antenna array signals for operations such as detecting the direction a signal is coming from (direction finding or DF), focusing the direction sensitivy of the antennas (beamforming), and cancelling out signals coming from unwanted directions (interference cancellation/nullforming). At Raytheon, I worked in a group conducing research into simulating DF and beamforming algorithms. Of particular interest were the "superresolution" algorithms like MUSIC and ESPIRIT, and adaptive algorithms such as Constant Modulus Algorithm (CMA) that exploit features in particular signals such as the constant modulus property of FM radio signals. I simulated signals and algorithms primarily using MATLab and Simulink. But it wasn't strictly theoretical---At Raytheon I was involved in the implementation of a CMA algoritim in an actual fielded system (on a AD Sharc processor). At Tektron, I also implemented simple DF algorithms into a two-antenna system to give direction finding ability to a hand held device (this was an FPGA design on an Altera Cyclone II). So I have pretty thorough understanding of these algorithms, and most other aspects of antenna array signal processing in the areas of beamforming and DF.
The other type of geolocation system for which I have experience consists of several receivers, located a distance apart from each other (perhaps miles), but coordinated in time and frequency, and comparing the time samples received at pairs of receivers to determine signal time difference of arrival (TDOA) and determining geolocation from the time difference measurements. I've done IR&D work about TDOA at several places---Raytheon, Tektron, and DGS. While working at DGS, I built and fielded an actual working TDOA demonstration system. Each TDOA receiver station used a DGS configured radio system with the ability to record and download GPS time-stamped samples. Three TDOA receiver stations were located around the Tysons Virgina area. I created software to coordinate the three stations to tune to a given frequency, simultaneously record a time sample of the baseband signal, and download the samples to a common processing location, where they are cross-correlated to determine TDOA and geolocate known transmitters in the area. I have a good mathematical underatanding of using cross correlation algorithms for measuring TDOA, including issues like conversion to frequency domain processing via FFT, and compensating for frequency drift between receiver local oscillators via a two stage optimization process alternating between maximizing cross correlation over time and frequency.
In fielded systems, much of my development work has been implementing RF modulation and demodulation algorithms. At Raytheon, I developed and implemented algorithms for demodulation of esoteric signals of interest, in particular demodulation of signals modulated with intentional intersymbol interference for increased data throughput. At Tektron, I worked with adaptive time domain filtering of many types of signals, for example for equalizing distorted QAM signals. I have a thorough understanding of DSP operations related to RF processing such as digital downconversion, decimation, and filtering. I also understand how these operations are represented in the spectral domain, with Y axis symmetry that applies to real signals, and how Hilbert transform relates the real and imaginary components in a complex representation of a real signal.
Being a DSP affectionado, I have a special place in my heart for Matlab and Simulink. They have been my workhorses for algorithm development---I have used them in particular at the following positions:
In my school days, I had a personal coding project to develop an interpreted language to call the routines of the IMSL matrix function library, which was leased by my school. My idea was to make a convenient way to use this library, without the need for compiling and running a simulation program. I developed a standard format for reading and writing matrices to and from files, and a standard command language for instructing the program to process the matrix files with various IMSL routines. Years later, after I first discovered Matlab, I realized that I was trying to create Matlab myself before it existed! (Of course, even then Matlab far exceeded the primitive framework that I created.)
I find Simulink most useful for interactive development, as it allows sliders and other graphical inputs for adjusting parameters and seeing the results on the fly. But Simulink is more than just a graphical representation for algorithmic development---it can be used as the basis for a Model Based Systems Engineering (MSBE) approach to development, where the model provides the actual definition of the system, and the embedded code is produced directly from the Simulink model. Companies are moving towards a MSBE philosophy for system development. I have tried out the generic code generation function of Simulink, but at the companies where I have used it, I attempted to proponent of the use the embedded code generation of Simulink to produce the actual released code. This would be in furtherance to merely being a convenient block diagram-based simulation tool.
I have a great deal of experience as a Systems Engineer and performing systems engineering functions, notably at the following positions:
I am well familiar with Military standards applicable to systems engineering, such as MIL-STD-471A (Maintainability/Verification/Demonstration/Evaluation) and MIL-STD-498 (Military Standard Software Development and Documentation). My writing and communication skills are useful in these positions, as well as being good at researching and understanding documents like product specification sheets. I also think I have good people skills, which is helpful when working as a systems engineer and having to frequently interact with code developers and other engineers.
I don't love working exclusively at a computer monitor in a cubicle (although that is indeed where I spend a lot ot time)---I do like to get my hands dirty doing more direct work. For me, this means getting into the lab or the field and performing testing. I have worked as a Test Engineer at several positions---General Dynamics, GE Healthcare, and Tektron in particular.
I have extensive experience with National Instruments' test software packages, including LabView, Teststand, and Veristand. Labview is great---I like it almost as much as Matlab! To me it's the most intuitive of the MBSE type programs.
I first used Labview at my position at the Naval Research Laboratory, where I developed Labview programs for controlling experiments related to measuring AC losses in high temperature superconducting materials subject to magnetic fields. These Labview programs controlled the experimental apparatus by ramping up AC current and magnetic field generation, while monitoring experimental variables such as magnetic field strength, voltage measurement (4-wire voltage measurement was necessary for accurately measuring these infinitesimal superconducting effects), and lots of other environmental variables such as the temperature of the liquid nitrogen bath. This experiment used some very esoteric scientific equipment (like the superconducting magnet to generate fields) for which standard Labview VIs of course did not exist, so I had to read and decipher obscure manuals to create custom VIs for interfacing with this equipment. The LabView program performed the experiment, collected the experimental data, and even performed some initial processing on the data (such as compensating for system inductance).
I used Labview even more extensively at GE Healthcare, where I worked as a Test Engineer on a product assembly line that made incubators for prematurely born babies. I created a complete turnkey Labview-based program to perform final qualification testing. This test program interfaced with several temperature, light, and humidity probes that were placed in the incubator, as well as a cable interface directly to the unit under test (UUT) to read parameter values reported by the unit. I worked closely with test engineers on the production floor to develop a test system that was intuitive and user friendly. The final program, which consisted of dozens of Labview panels, was compiled into a Windows excutable, and was distributed for use by the testing group. The benefit of this automated testing was to reduce the testing time per unit to some precise value that was measured by management (the figures were something like 27 minutes of manual testing reduced to 14 minutes automated testing). The automated test program created an electronic data record to accompany each tested unit containing all testing data and results. I personally believe that this completed Labview project, which is now being used in GE factories abroad, is perhaps the most consequential thing I have done for a company!
I continued to use Labview at Tektron, where I hoped to introduce more automated testing procedures. I had some success, but Tektron is a small company with an exclusive product (product deliveries are measured in dozens, not thousands or even hundreds!), so automated testing was less impactful than at GE Healthcare. The tests themselves were more elegant and mathematically intensive, testing transmitter parameters like modulation bandwidth and third order intercept point (IP3). At Tektron I developed Teststand programs as well to conduct test scripts and produce test reports.
I've used LabView and LabView related products at General Dynamics Land Systems as well. The embedded code I was developing for a military vehicle was tested on a bench that used a combination of actual hardware and simulation to replicate the vehicle electronic systems. This test bench implemented hardware in the loop (HIL) under control of an extensive Veristand program to simulate inputs and outputs. I interfaced frequently with the Veristand developers to modify and extend the Veristand program as necessary. For example, when the vehicle battery got upgraded, and the new battery used CAN control messages with an extended M1939 format that was not yet supported by the software---I worked with the developers to modify the Veristand program to test this functionality.
I'm very comfortable with all types of laboratory equipment, including scopes, spectrum analyzers, network analyzers, and logic analyzers. I'm particularly good at using this equipment in extended ways: for example, at Tektron (and other places), I frequently used the "zero span" setting to operate a spectrum analyzer as a simple RF downconverter, for detailed examination of raw transmitted digital data. For fun, at NRL (a repository for ancient equipment) I once set up an old unused HP8552 spectrum analyzer as a shortwave radio receiver---thousands of dollars of high performance test electronics operating as a primitive mundane radio. I have interfaced to lab equipment using GPIB and Ethernet, writing Labview blocks (and scripts in other languages) to download measured data---a procedure I've done frequently at GDLS, Tektron, and DGS.
I am fully competent with bus analysis software packages, primarily Vector CANoe for use with CAN bus monitoring, and Wireshark for monitoring Ethernet IP packets.
I consider myself fundamentally an Electrical Engineer that does programming, not the other way around. I've performed circuit design at the following positions:
I've never lost my love for basic circuit design. Back in the day, I was a Radio Shack scrounge, frequently buying surplus parts and chips for experiments. I bought a discontinued chipset used in the 80s for video game sound effects, set it up to make a burst of white noise on a trigger, and mounted it in an old guitar effects stomp box---it was used by a local band as a handclap sound effect. When my junker car in college had a slow radiator leak and frequently overheated unless regularly refilled, I took a transistor, measured the bias in boiling water and freezing water to find its temperature characteristic response, and installed the transistor into the original radiator temperature probe (which was a mere thermocouple switch that activated above a certain temperature). I built a voltage divider network matching the temperature characteristic, with red LEDs that lit to indicate when overheating. This system warned me when the car was about to overheat, allowing me pull over and add water, forestalling forever the expensive repair of the leaky radiator (although my friends were reluctant to ride in my car with wires running out of the hood).
I have used all the circuit schematic capture programs over the years, being most familiar with Altium Desiger and Cadence Virtuoso. While I haven't made the most intensive circuit designs, I have designed up to 6 layer PCBs with some complexity, including the use of blind vias. I have some experience with producing flex circuit design---some Tektron products with unusual form factors use flex circuits. My circuit experience has mainly been at frequencies below microwave range, so I don't have extensive understanding of issues like parasidic capacitance. But I think I do have a good appreciation for what causes these issues, and how to avoid them with good circuit design techniques like keeping high frequency trace lengths short, avoiding stubs, and keeping good trace geometries, with symmetry of high frequency traces and use of ground planes around traces. I also have experience with other schematic capture issues, such as creating footprint models for unusual parts.
I occasionally use Spice and Spice-like circuit analysis tools to do circuit analysis for particular design problems that come up all the time. For instance, one product called for a USB port to also operate as a RS-232 port, which is a completely incompatible voltage standard from USB, and I used Spice to desiged a circuit to allow the port to be used for both, isolating and protecting the USB and RS-232 parts of the circuit from each other.
Most of my programming is done in C or C++, but I have capabilities in other languages as well. I am quite capable at Python, which I have used primarily for Windows-based GUIs and user interfaces. I could be using Python as a simulation language as well, along with Matlab/Simulink, but I have found it most useful for its extensive graphics library and its text processing functions. I have written Python scripts to read webpages and extract information from the website code (one example would be a program that bypasses a login password and still shows the underlying website information). I'm somewhat capable in HTML, CSS, and Javascript, as I have needed to program embedded webpages for device control---these webpages often need to show real-time displays (such as bargraphs showing signal levels), and I have created AJAX controls to smoothly update these displays, without the flicker that would be seen by updating these displays with entire page reloads. Recently, I've learned qtWidgets, and used it to produce GUIs and graphical displays. I feel like qtWidgets may end up being the prefered solution for user interfaces that are not webpage driven.
These are just some of my capabilities. I'm never going to stop learning, so I feel like my my capabilities are only limited by the time I have avalable to dedicate to learning new things.
“Everything should be made as simple as possible, but not simpler.”
– ALBERT EINSTEIN
MARK H. PATTEN
MARK H. PATTEN
Electrical Engineer/Embedded Programmer