Wednesday, July 18, 2012

RIP Time division multiplexing

I recently had the opportunity to play with land mobile radio technologies and integrate them with VOIP software. While doing it I was reminiscing about how just a few years ago before widespread green side deployment of IP technologies we had to multiplex signals and conduct intricate planning. I searched online for a piece of multiplexing hardware that I used to have a love/hate relationship with, the FCC-100. Looks like they are finally killing it this year and retiring the technology in favor of IP specific tech. Rest in pieces my little signal multiplexing frienemy. I hope they have conditioned diphase for you to time division multiplex in multiplexer heaven. 

http://www.ultra-dne.com/Home/Products/Archive/AN-FCC-100.aspx

More concerning is the amount of hesitation I've seen some of the engineers in training here display over having to diagram networks before deploying them. The systems we are working with include land mobile radio nets, cellular phones, voip phones, servers, and desktop computers all communicating in various ways to each other. A person can't just start installing things and start configuring a system like that without creating some serious discord and spawning network gremlins that will haunt you as long as the system lives. Kill the gremlins early. Learn how to draw a diagram and spot the system gremlins before you give them life. The FCC-100 taught me that lesson years ago, and it was relatively simple (albeit less self-correcting) when compared to modern technology. 

Here's an idea. Ask your engineers to draw a diagram of the network or produce one. If they can't, consider it an opportunity to pursue the next time you make a system addition or change. You can reduce your cost and increase your network reliability when you understand how everything is interacting. It's almost like a gift... cash is always the best gift. But beware attempting the diagramming endeavor without a catalyst. That is normally a waste of time. If you start out trying to do such a thing with a non-discreet hypothesis it's impossible to tell when you're done. People get frustrated, both the managers who expect magical results and the engineers who are left to run on an impossible wild goose chase. Any effort needs to be tied to a discreet goal. i.e. "show me in detail how new technology x impacts or interfaces with our systems."