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.
EMBEDDED CODE DEVELOPMENT
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:
- General Dynamics Land Systems: I maintained the codebase for the multiple power control modules in the Army Booker M10 tank.
- Raytheon: I developed code for various modules an airborne signals intelligence receiver system.
- L3Harris: I maintained the codebase for the Falcon III military software defined radios.
- Boeing: I developed code for a simulation system used for integrating avionics for the Space Launch System rocket.
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:
- Tektron: Tektron manufactures high end specialized digital audio transmitters and receivers for a government customer: Examples of Tektron products I worked on include hand-held diversity receivers controllable with buttons and LCD display, and remotely fielded equipment controllable via embedded webpage.
- Digital Global Systems: I engineered, built, and programmed a prototype TDOA geolocation system consisting of three receiver stations, each built using DGS's radio product interfaced with GPS time standard, placed at locations around Tysons Virginia area, and demonstrated geolocation on local transmitters.
- Fraser Optics I designed, built, and programmed a Windows Embedded prototype of a ruggedized stabilized camera system, which included pan/tilt/zoom control, and control of visible and infared camera settings.
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.
C/C++
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.
OS
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.
PROCESSORS
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.
FPGA
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.
ALGORITHMIC DEVELOPMENT
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:
- Tektron:I implemented algorithms for RF signal processing into real-time systems, involving digital demodulation, forward error correction, audio filtering, and diversity selection based on bit error rate. Also explored adaptive filtering algorithms for channel equalization of QAM signals.
- Digital Global Systems: I implemented a time difference of arrival (TDOA) algorithm as part of a prototype TDOA geolocation system, which performed time domain cross correlation algorithms for measuring TDOA and compensated for frequency drift between receiver local oscillators via a two stage optimization process alternating between maximizing cross correlation over time and frequency.
- Raytheon: I implemented antenna array processing algorithms, including superresolution DF (MUSIC, ESPRIT) and adaptive LMS beamforming (CMA). I implemented algorithms for demodulating esoteric signals of interest into airborne software radio collection system. I also implemented audio compression algorithms (ADPCM and subband coding) for digital downlink.
- General Dynamics Land Systems: I performed some generic algorithmic work, including: I designed the algorithm for controlling the hydraulically powered cooling fan, which reads temperature transducers and alternates between a open loop mode and closed loop PID mode to adjust target temperature to meet full load cooling requirements. I also performed analysis and made improvements to the AC compressor motor control algoritim, adjusting PID coefficients and placing debounces on pressure transducer measurements.
GEOLOCATION
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.
RF PROCESSING
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.
MATLAB/SIMULINK
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:
- Tektron: I simulated and tested algoritims for digital demodulation, forward error correction, and audio filtering in Matlab
- Digital Global Systems: I designed algorithms in Matlab for performing TDOA analysis, and tested them with simulated data generated by Simulink.
- Raytheon: I used Matlab and Simulink for designing and testing antenna array algorithms for beamforming, direction finding, and interference cancellation. Also used Matlab to test audio compression algorithms
- General Dynamics Land Systems: I used Matlab for analysis of various problems, including cooling fan speed control. I also used it to analyse the steps of the air conditioning compressor motor speed, which is controlled by the embedded program.
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.
SYSTEMS ENGINEERING
I have a great deal of experience as a Systems Engineer and performing systems engineering functions, notably at the following positions:
- Raytheon: I was a systems engineer for many years for airborne collection system, writing all types of software requirements, specifications, and interface documentation.
- General Dynamics Land Systens: I wrote contracted documention for Mobile Protected Firepower program, including Software Design Document and Software Requirements Specifications for Power Control Module.
- Digital Global Systems: I system engineered TDOA collection system, including integrating GPS time standard and digital acquisition to radio receiver.
- Tektron: I performed system engineering for many Tektron products (in addition to doing everything else)
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.
TEST ENGINEERING
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.
LABVIEW, TESTSTAND, VERISTAND
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.
LAB TEST EQUIPMENT
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.
VECTOR CANOE/WIRESHARK
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.
ELECTRONIC DESIGN
I consider myself fundamentally an Electrical Engineer that does programming, not the other way around. I've performed circuit design at the following positions:
- Tektron: Most Tektron products on which I performed system engineering and embedded coding I also had roles in circuit design, particularly the digital electronics portion of a device, Typically this involving an FPGA and a microcontroller with peripheral devices for interfacing, voltage regulation, etc. Typical board complexity was 4 layer (two digital trace layers, Vcc, and ground plane) with some up to 6 layer.
- Raytheon: I designed and built many boards for a VME bus based receiver system, the most complex being the digital timing standard board, which consisted of multiple shock-mounted ovenized crystal oscillators and FPGA circuitry performing as a frequency counter to receive a GPS timing standard of 1 pulse per second and use it to discipline the oscillators via voltage feedback control.
- Fraser Optics I designed the main circuit board for a prototype of a ruggedized stabilized camera system, which interfaces for button and joystick control of visible and infared camera settings and pan/tilt/zoom position.GE Healthcare I designed many small circuit boards for interfacing testing equipment to units under test (UUTs).
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).
CIRCUIT DESIGN/LAYOUT
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.
SPICE
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.
ADDITIONAL CAPABILITIES
PYTHON, QTWIDGETS, HTML
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