Application Engineer II
Spotter Global · Apr 2020 – Jul 2023
My work at Spotter Global covered the deployment and support of FMCW radar systems used at prisons, substations, airports, seaports, and private properties. I worked with sites from initial survey through commissioning and long-term support, which meant understanding not only how the radar was supposed to behave, but how physical placement, surrounding infrastructure, weather, traffic, wildlife, networking, cameras, and customer requirements affected it once it left the lab.
A large part of the job was turning those variables into something a customer could depend on.
01
The Field Work
Most days started with active support cases. A radar might be producing incorrect tracks because its physical position did not match the height, pitch, yaw, or role configured in software. Another site might be generating too many alarms and need filtering based on direction, speed, location, or behavior. Multi-radar deployments introduced channel-separation requirements, while reflective environments could create problems that were not obvious until the system was operating on site.
Metal was one of the most persistent challenges. Substations, parking structures, airports, and seaports could produce difficult reflections and unusual tracks depending on where a sensor was mounted, how it was angled, and how much power it was transmitting. I would use range-Doppler maps and live track data to evaluate noise, adjust channels and power output, and determine what should be handled through sensor configuration, geographic filtering, or classification rules.
The environments varied significantly. Desert prisons could be relatively clean from an infrastructure standpoint but introduce wildlife and environmental movement. Substations were dense with reflective equipment. Airports combined metal, vehicles, people, and existing frequency-management requirements. Seaports added ships, waves, birds, and changing sight lines. Even a comparatively simple residential deployment could require separating a person from trees moving in the wind or animals crossing the property.
Site surveys were usually performed with a portable radar kit containing the sensor models we expected to use, along with a small PoE network and either a battery-powered server or a virtual machine running on my laptop. We would test candidate locations, collect tracks, identify blind areas, and document environmental conditions that could affect the final installation.
During commissioning I tuned the radar, verified its physical and virtual alignment, and checked its integration with PTZ cameras so that radar tracks and camera positioning agreed spatially. If a problem could not be addressed remotely, I traveled to the site and worked directly with the equipment. At some secure locations, remote access was not permitted at all, so troubleshooting meant physically being there with the server and sensors.
The job required a lot of independent judgment. I was often the only person from Spotter physically present during a survey, commissioning, or troubleshooting visit, so I needed to be comfortable making decisions about placement, configuration, filtering, networking, and integration while also explaining those decisions to the people responsible for the site.
02
Making It Repeatable
Supporting systems after installation gave me a strong incentive to make deployments easier to configure and easier for the next person to troubleshoot.
I wrote internal and customer-facing training material, created SOPs for different types of sites, and built baseline configurations and datasets for environments such as deserts, mountains, snow, rain, heavy vehicle traffic, and highly reflective areas. These were not intended to replace site-specific tuning. They gave engineers a useful starting point that could be combined with local data instead of rebuilding every configuration from nothing.
A significant part of that work involved the behavioral and classification models running on the server. Getting useful results from them depended heavily on the quality of the data being collected and how that data was curated. I worked with field data to identify useful samples, remove misleading or ambiguous examples, and evaluate how changes to the dataset affected classification behavior.
More data was not automatically better data. A model could become less useful if too many poorly defined variables or inconsistent examples were introduced. I had to understand how the models behaved closely enough to recognize when additional training was improving a site and when it was introducing more uncertainty.
That became especially important at difficult deployments. A drone and a bird, for example, could look surprisingly similar in individual radar measurements while behaving very differently over time. Vehicles, wildlife, waves, weather, and recurring environmental activity created similar problems. We used a combination of classification data, behavioral filtering, GIS information, statistical analysis, and direct site observations to determine which characteristics actually separated a useful alert from background activity.
I also trained new hires on interpreting range-Doppler maps, evaluating good versus misleading data, building useful training sets, and recognizing when a model was being given more information than it could use effectively.
Software testing was another regular part of the role. Application engineers were often among the first people using new radar firmware and server releases outside controlled development environments. I would take equipment into the field, collect data, document bugs, and write reports describing changes, inconsistencies, and behavior that could affect customers. Because I was also supporting those customers afterward, I could connect what I saw during testing with the problems that appeared in real deployments.
One of the larger changes I advocated for was moving away from proprietary physical servers toward virtualized deployments. Providing the server software as an image that could run in a customer’s Hyper-V or VMware environment reduced the amount of dedicated hardware we had to bring into sites and made it easier to work within each organization’s existing security and infrastructure requirements.
Virtualization also changed how I worked in the field. I could run the server environment from my laptop, test multiple software or model configurations, route sensor traffic through virtual networking, and travel with considerably less equipment.
My previous networking experience became particularly useful during that transition. VLANs, switch configuration, ports, PoE behavior, and network segmentation were not always the first things other engineers considered when a sensor stopped communicating, so I became a common escalation point for those problems. I also documented hypervisor-specific issues and helped the rest of the team become more comfortable troubleshooting the network and virtualization layers themselves.
03
What Stayed With Me
Spotter was where I became much more comfortable making decisions in environments where there was rarely one correct configuration.
Two sites could present what looked like the same problem and require very different solutions. A filter that worked at one substation could be inappropriate at another. A radar configuration that behaved well during the day could produce different results at night. A model that performed well in one environment could behave very differently once the surrounding conditions changed.
Working closely with classification models also changed how I thought about data. The usefulness of a model depended on much more than simply collecting more examples. How the data was selected, how clearly the behavior was defined, where the data came from, and what operational rules surrounded the model all affected the result.
That pushed me toward a more analytical way of working. On difficult sites, we relied on sensor data, statistics, GIS analysis, environmental observations, and actual site behavior rather than intuition alone. Season, time of day, traffic patterns, weather, wildlife, and physical infrastructure could all change the outcome.
It also reinforced the importance of understanding the entire path around a piece of technology. A radar problem might actually be a placement problem, a network problem, a camera-integration problem, a classification problem, or simply a mismatch between what a customer expected and what the environment allowed.
My role sat where the product met the field: configuring it, testing it, integrating it with the surrounding environment, identifying where it failed, and feeding what I learned back into documentation, training, standards, and future deployments.
That experience still affects how I approach technical work now. A design can be perfectly reasonable on paper and still fail when it encounters the real environment. The useful part is being able to understand why, make a defensible adjustment, and leave the next deployment easier than the one before it.
