Tool suite for a passive tracking system

I spent the first year or so at this job analyzing issues the system had, meeting with users, and implementing software changes. After a while I had a pretty good picture of what was needed to help people understand and maintain the system and the databases that were used with it. By that time, I had also figured out the most complicated parts of my team's job and knew what was needed to make things easier.

This was the first passion project I made. By passion project, I mean that I was obsessed with it. I thought about it and worked on it constantly, all while doing the normal work required by my job on top of it. When I was not at work, I would study and create prototypes that would later be recreated on the private network at my job. I even thought about it while laying in bed at night. This kind of behavior has become routine with several of the projects I've done, but you always remember your first.

This program had several different tools inside of it. Some of these were completely new and some were revamped, more functional versions of tools that already existed. It used the WPF Windows Ribbon to manage most of the actions, styling, and options for each tool. The theme was completely customizable and was based on each component type in xaml.

Database Maintenance

The structure of the relationships between the different database objects made this more complex than the average CRUD application. Each parameter also required very specific validation. The overall structure was based on a hierarchy where the precision became greater with each new level. Each level had bounds for each parameter which had to be tracked and changed accordingly when the values at the other levels were changed.

There was already a separate tool being used for database maintenance, and it was written with Microsoft Access. It was a functional tool, and it was usable if you knew exactly what you were doing. The tool I made was meant to make it easier to understand the hierarchy of objects in the database, which dramatically helped understand how the system software processed data for correlation.

The main difference between this tool and the existing one was that this tool showed all levels of the hierarchy for each emitter at the same time instead of forcing the users to dig down over and over again to see very little information. This made it easier to do pretty much everything.

Ambiguity

Another tool that was part of the suite was a new capability that discovered entries in the database that are ambiguous. This means it would process the database and find records that had overlapping prarameters according to correlation rules. These entries need to be examined to check for errors and increase the confidence of an ID.

There are whole offices devoted to maintaining these databases. The intelligence they used to program records was great, but it helped the system to narrow down the parameter values as much as possible so the system performance and accuracy could be increased.

Pulse Data

The third tool in the suite was used for pulse data analysis. It could load in the pulse data found during missions by the antennas, then display and filter it. It could also break the pulse data files down into smaller files to make analyzing the data or even loading them possible due to their large size.

This ability was helpful for improving signal analysis. We could identify issues with the sorting/binning algorithms by looking at the pulse deltas and finding the right patterns. Each mission had a huge amount of pulse data, so being able to pull out pulses with certain frequencies and other parameters, opened up several new possibilities.

Scenario Creation

This tool was possibly the most helpful one for the work my team did. It included a geographical map that would allow placing emitters and waypoints, as well as setting custom parameter values or using the values from records in the database. This capability was very important for testing the system software changes, and making a tool like this had been attempted at least once before.

This tool was special mostly due to the user interface and the algorithms used to program scenario emitters that would match with the signal analysis the system performed. In other words, this tool could take the parameters for emitters in the database and turn it into pulse patterns that the system would correctly ID. With this tool, a scenario that covered every emitter entry in the database could be created and tested to see results.

Scan Analysis

This tool included something not many people had experienced. Operators could manually adjust what the system would scan, but the system also automatically generates a scan table based on the database entries. This tool used the code from the actual system to calculate and show the user what the default scan tables would be.

I don't know how helpful this was for operators because a lot of them had their own techniques to define the system scan parameters. For my team, it helped when making software changes to the algorithms calculating the scan tables. We did change these algorithms at one point to enhance scan speed.

Database Comparison

Another tool allowed users to compare multiple databases and see what was different. It would show exactly what had changed in a database and allow merging or modifying the data. This was a capability that the database maintainers could find quite useful. To enhance speed and accuracy, databases were specifically programmed for different regions, so being able to see what records were in each database side by side was helpful.

Correlation

There was another tool that performed correlation, but it would basically read an emitter report and then output a csv with the results using any database. This new tool would run the test and display the results in the GUI. Users could select report entries and immediately see the correlated database records.

This correlation tool was able to turn software changes made to correlation on and off as well, which helped see the effects of the changes. This tool suite could also read in a full set of binary report data and display all the data like a database explorer tool would. It could also view raw data from other specific data sources that had been previously much harder to view or maintain.

Conclusion

I remember the work I did while at this job fondly, and I feel like making this tool suite turned me into an actual programmer. The team of people I worked directly with were great, the system was complex enough to be interesting, and our mission was clear. The operators we worked with were passionate about their jobs and were always interested in what we were doing.

I also wish I could go back knowing what I know now and at least redo the interface for this tool suite. It was nicer than most of the other tools I've seen, but I could make it look so much better.