I listen to sports talk radio on my commute every morning. I never put much thought into how it works, all I know if that I hit a button and voices magically appear and tell me how terrible [insert Cleveland sports team] is. That was before I worked with Bird Technologies.
For 70 years, Bird has been one of the leaders in the world of radio frequency monitoring and system design. Basically it is a group of very smart people who use an array of equipment and complicated math formulas to help make their clients' radio frequencies stronger and clearer. How do they determine all of this? They use math...lots of math.
You remember high school math classes? They'd give you this giant textbook and you would work through a few mind numbing pages a day for 9 months. Now imagine getting one of those and trying to read it like a novel in a week. Sounds ridiculous, right? You don't know the half of it...
One of the things I love best about my job at Trait is that I get to experience many different types of industries. To build effective software for a company, you really have to learn the intricacies of their business (and industry as a whole). That's why I was excited about working with Bird, I had ZERO experience with anything RF (Radio Frequency) related and was looking forward to learning more about it...I had no idea what I was getting myself into.
My introduction to Bird went something like this:
Me: ”Hi, it's great to meet you. Do you want to discuss the project?”
Bird: ”Eventually, but first we thought we'd give you a little introduction to RF monitoring.”
Me: ”Sounds great, where do we begin?”
Bird: ”Here are about 27 books about the history of RF monitoring and the math supporting it, read these first.”
Me: ”hahahaha...”
Bird: [Silence]
Me: ”haha...ha....”
Bird: [Silence]
Me: ”huh?”
So my first 3 weeks at Bird I read math books. Not just math books, but math books that referenced words I didn't know the meaning of. That means I got to spend the better part of 8 hours each day going back and forth from math textbooks to a dictionary of RF terms. There isn't a word in the English language that can describe the frustrating monotony of those first days; I just know I lost a bit of my soul when I got to the page on converting dBm to Milliwatts.
I'm going to try to explain what frequency filtering is without getting too technical so, for the RF savvy, please forgive me if I leave some (a lot) of details out. Basically, when you look at a giant antenna sticking up out of the ground, it's really just a metal stand that supports a bunch of antennas attached to the top of it. Those antennas have cables that run down the tower to a room or building at ground level where all of the hardware lives that controls the frequencies sent out by said antennas. Here's the crazy part; frequency signals can overlap each other and cause interference, to filter that interference out there are racks of these brass canisters called cavities that the cables from the antennas are attached to. These innocuous brass cans help filter out potential interfering signals which makes the inteded frequency signal clearer.
Now, there is a lot more that goes into these systems but this is a major part. Bird does 2 things; 1. They hook up hardware and software to analyze a system and determine how a set of frequencies are performing in a certain area and 2. They look at the results of that testing and figure out what kinds of cans (and/or other hardware) are needed for a certain frequency to be able to exist on that antenna. The bottom line is that it all comes down to signal strength, and the more cans that are needed to clear up a frequency, the weaker the signal coming in or out. Bird optimizes the cans you need to get the strongest signal and best performances out of a system.
In spite of what I saw as an incredibly advanced industry, the process for determining what cans are needed was surprisingly manual. Engineers (the incredibly smart team that design these systems and will always be able to talk circles around me) would look up cans on a printed diagram sheet created in the 70's to determine how much signal strength would be lost and how much clearer the frequency would be with each can. They also had multiple spreadsheets to determine other variables and, along with that, even used some old DOS based programs to accomplish other tasks. They would then type all of their results into a document to send to the client. My task would be to take all of those manual processes and create an application to help the Engineers be more efficient.
Now the great thing about working on an application like this is that there is nothing like it out there so the sky is the limit on what you can do with it...
The bad thing about working on an application like this is that there is nothing like it out there so the sky is the limit on what you can do with it.
The Engineers have spent their careers doing this manual process and have had a lot of time to think about what they would do to make it more efficient. That means that our initial design meetings were all-day events. Having no limits or reference allowed them to throw out every idea they've ever thought of. They are passionate about their work, I get it. Hell, bring 10 of my buddies to a table and have ask them what the Browns need to get out of the cellar...it will be the craziest mishmash of ideas you've ever seen.
In spite of the industry, most software architecture meetings are pretty similar with many ideas and discussions going off in different tangents. I have gone through this process many times before and was ready when our meetings started to go that way. Part of my job is to filter out the wealth of ideas that come from software design brainstorming sessions and put together a clear, focused blueprint on what we are going to accomplish and how we are going to get there. I'm not saying it was easy, different people value different pieces of any software differently so sometimes it was a fight to keep things on track. But at the end of the day we were always able to bring multiple ideas together and emerge with a plan for a single, compromised application.
The end result of all of the books and the brainstorming was an intuitive, desktop application that brought all of their manual tasks into a single system that we built from the ground up. It automates each of their processes and has Office and Sharepoint integration to streamline their workflow, easily generate client reports and track information more efficiently. What used to take 2 weeks to accomplish can now be done in a matter of hours.
It is continually evolving and will eventually be able to suggest a full system design based on a number of factors and engineer input. It has a complex SQL server backend and is driven by a mountain of mathematical functions and specific RF business rules. Not to mention it was built with the future in mind and has an API for integration into any number of different software packages and devices (like being able to see your system on an Ipad in real time). With over 300,000 lines of code it might be the most advanced piece of software in the RF system design industry.
Once we got to a stable point with the System Design application we were tasked with building Bird a separate application to generate reports from the system analysis side of the company. It was even more complex and involved even more math than before! It interfaced with a spectrum analyzer and used webservices to....you know what, you've been through a lot, I'll save that story for another day.
Like I said, I love learning new industries. Even though it may only ever apply to Bird Technologies, I genuinely enjoyed getting to know the ins and outs of the RF world. Especially since it gave me the opportunity make the lives easier of a great group of incredibly talented people who really care about what they do. FYI, I'm more than happy to let anyone in on the RF experience so go ahead, ask me about intermodulation, noise floor monitoring or the effect antenna separation has on frequency isolation requirements....I dare you.