Dick Goldman K2ZWF started a business (Telesaver) in 1980 by aggregating residential telephone customers into large enough quantities to achieve significant cost discounts on long distance calls. (Actually, the first name of the business was Consumer Alternatives.) He purchased "business accounts" from SPRINT (Southern Pacific Communications) which offered accounting codes. These were intended to permit businesses to attribute costs between different departments or employees. Customers dialed a local access number and entered a secret authorization code followed by the destination number and the unchecked accounting code. The resultant bills provided were broken down by accounting code. Selling a single account (authorization code) to multiple users and instructing each to use a different accounting code kept the cost down (there were quantity discounts plus monthly service charges). This method worked because Dick initially sold service to friends and family, etc. Everybody was saving money and most were honest. Dick received monthly billing fanfold printouts from SPRINT, and he literally cut up the bills with scissors and mailed them out to each individual customer. He could charge them less than they could get any other way, and still have a profit margin after paying the SPRINT bill. While this method had its advantages -- namely no line or equipment costs, plus he could sell to anyone served by a city where SPRINT had a presence -- he knew that it could not last, or expand indefinitely. The business itself was at the mercy of SPRINT's pricing policies, plus it depended upon customers entering their own accounting codes properly. (I should add that this was completely above board, he told SPRINT what he was doing and they were glad to get the business that they wouldn't otherwise get.) Here are a couple of newspaper articles about the business; they're undated, but it looks like they were from 1983.
Dick wanted his own switch and telephone lines. This would give him control over the customers and the outgoing line selection. With the inclusion of WATS (AT&T) lines, he would be able to offer "universal" service for the first time. SPRINT (it worked the same way with MCI and the other carriers) only terminated calls to those cities in which it had facilities -- so a user didn't necessarily know if a call would be placed or not without consulting a service book or just trying it. Selling universal service would be a big selling point. There were some existing small switches, but Dick considered them to be prohibitively expensive and didn't offer the routing flexibility he desired.
Being a ham, he was on the local repeater and was an autopatch user. He knew that I had constructed the control system for the BARC repeater which incorporated telephone calling. Dick managed to convince me to join his new business and build him his switch. I finished up my schoolwork in October 1981 and that is when I joined him at Telesaver. At the time he had just rented an office at 7 Greenspring Valley Road (at the corner of Reisterstown Road, the county has since actually moved the sharp angled intersection a hundred feet or so). He had hired Christie Harmon, a high school girl, to help him with all of the clerical work. I guess that made me the third Telesaver employee.
The UVC-1 card was one thing, but to handle multiple lines they needed to be housed in card cages.
I came up with a two piece front/back backplane configuration which re-routed the various signal lines into aggregate connectors for distribution to the switching matrix.
(I think this was done for the Telcro I, possibly it was Telcro II.)
The UVC-1 and associated card cage design were used on the
We named our first switch the Telcro I for Telephone Least Cost Routing switch. It was not meant to be expandable beyond its 12-path design (i.e. it could accept incoming calls on 12 lines and route them to its 12 outgoing lines -- sometimes called a 24-port switch). I finalized it in April 1982.
Then Dick went to order 24 telephone lines for our Greenspring Valley Drive location. Turns out that it's not so easy to get that many phone lines installed.
I remember he had to negotiate to get C&P to run a new (bigger) cable for our building -- it took some time -- but eventually we had our very own facilities-based switch operational.
Telesaver began offering "Universal" service to (some of) its Baltimore customers!
The switch had only a few dB's of loss (primarily the two UVC-1 transformers), but we found after installation that we needed some circuit gain. This was needed mostly to counteract the local loop line loss that was inserted into the overall long distance call. It's not a trivial matter to provide bidirectional gain on a 2-wire line. Methods which use internal two-to-four wire hybrids are heavily dependent upon the terminating impedances on both ends. With a switched network, those impedances change, affecting the hybrid balance. The result can be "in a barrel" sounding voices, singing, echo, and even oscillations. We found a product (R-Tec VFR-5050) that worked in a different manner: it operated by dynamically varying the impedance and gain in each direction. It provided simultaneous audio gain variation in both directions, but it was not a VOX-like switching unidirectional gain system. When it increased gain in the direction of the listener, it correspondingly reduced the gain in the opposite direction. So it was completely stable and produced no audio artifacts. I was extremely impressed with its quick reaction to the parties' voices; it was nearly unnoticeable in its operation. We installed these amplifiers on the outgoing lines; I think we set them for something in the range of 4-6 dB gain. This Telcro I experience taught us how to address this matter, and since the Telcro II used identical line card/switching mechanisms, we duplicated the method and installed the amps at every subsequent Telcro II installation. You can see those amplifiers in the various Telcro II photos farther below.
I began the design for our next generation of switches in March 1982. The Telcro II would operate in much the same manner as Telcro I, but it had to scale to significantly larger sizes, and of course be readily manufacturable. Fears of potentially running into a brick wall of system slowdown as traffic levels increased led to an overall design which incorporated distributed microprocessor control. Assigning each processor a fixed workload meant that as the switches expanded in size, each processor's task would not increase -- there would just be more boards. Ultimately I received a patent on a Distributed Processing Telephone Switching System (issued on April Fool's Day 1986 -- but it wasn't a joke!). The prior art used a single high-speed computer to perform all switching functions. The major new part of the switch design for me was the provision of inter-processor communications. I took a straightforward approach by using a parallel backplane with 8-bits of data, 7-bits of board address, a parity bit, and a strobe bit. This was not a microprocessor bus, because I didn't want that relative high speed (megahertz) across multiple backplanes (and eventually across cabinets, too). The design constrained the communications bus speed to 10K transactions per second -- I didn't anticipate any speed problems with that, which was essentially an audio frequency. I was quite elated when I first got the board intercommunications working, since the rest would be relatively easy to debug given comms. I built in the ability to "tunnel" down -- from the TRS-80 (and later Intel SBC boards) via the serial port to the Master Controller, to any selected slave controller: low level commands to read memory, write memory, pre-load CPU registers, call subroutines, and return values up the communications chain proved invaluable for code development and testing. Hardware-wise I chose the 100-pin edge card connectors and backplanes used in the S-100 bus of the time because they were readily available. The first switch(es?) used those purchased S-100 backplanes -- then we manufactured our own.
The Telcro I used a single 16x16 switching matrix to accommodate 2x12 ports. This idea was extended to incorporate n2 16x16 switch matrix boards to handle 2x12xn ports. Architecturally, the design could span from 24 ports (with n=1) through 384 ports (with n=16). I knew that practically we would not be able to get that large, but felt certain we could make it at least to the 100-port arena.
Switch Card. The basic switching element was identical to that of the Telcro I, but it had added circuitry to address the card itself. At the time there were basically two types of chips available to perform analog switching (these were 2-wire analog switches). Transmission gate type chips were the easiest to control: a simple address with a strobe either closed or opened a single crosspoint connection (independent from anything else). But these parts presented several hundred ohms impedance when the connection was made. I was dealing with 600 ohm balanced 2-wire circuits, and didn't want to introduce that much loss into the switch. I had selected a very high quality 600:600 ohm transformer (physically large, but with low loss and low distortion) on the UVC-1 line card, which was part of this overall decision. (These decisions were made in the Telcro I design. I should mention that in the very beginning, Dick was researching competitive switch designs and feeding me all sorts of data sheets. Remember, Tim Berners-Lee first had the World Wide Web operational in 1991, which makes research much easier than in 1981.) I could have boosted the internal impedance to combat the transmission gate losses -- say to the 10K area -- but I feared that doing so would make crosstalk (between different customers on the switch) more likely. The internal wiring was with flat ribbon cable. Higher impedances on the audio lines usually called for twisted pair, preferably shielded. Which would have greatly complicated, or even made impossible, internal connections. I was mostly afraid that while a system might work alright for an initial small switch size, insurmountable problems might surface when we scaled the design up to larger sizes. So I rejected the easier transmission gate switch mechanism.
I think people thought I was joking when I said that IDC (insulation displacement connector) sockets and associated flat ribbon cable made the Telcro II possible. I wasn't. To implement a switch of size n, n2 Switch Cards had to be placed into a square matrix configuration. This meant paralleling all of the row and column wiring (the IDC connectors could easily be daisy-chained). Which became an interesting puzzle to solve for the larger configurations, i.e. figuring out how to layer the ribbon cables, folding them, etc. But it was a solvable puzzle, and we made up cabling specifications for each size switch and outsourced the cable construction itself. I believe Dan Dumler worked out much of the cabling specifications and drawings.
Switch Controller. I dedicated a microprocessor board to controlling the switching matrix, no matter what its size. There was a single Switch Controller per system, although it actually consisted of n boards. It needed to have output ports to control the SCR current sinks, and the number grew in size with the switching matrix. The addition really only amounted to an output port and open collector drivers, so I just populated a few chips on the Switch Controller Master (below left, sorry some of the chips are removed in this pic) circuit board to create multiple Switch Controller Slave (below right) boards. The bottom expansion edge connector on those boards was the microprocessor bus itself to permit I/O port expansion; but these boards were always mounted adjacent to one another, and a connecting ribbon cable spanning the 0.75 inch board spacing didn't present a problem.
Coupler Controller. I dedicated a microprocessor board to handle the line supervision tasks for two (UVC-1) coupler cages.
Each cage housed a dozen line cards; for a switch of size n, n incoming cages were placed on matrix columns and n outgoing cages were placed on matrix rows.
(Connections can only be directly made between a row and a column.)
Since each Coupler Controller handled one row and one column coupler cage, a switch of size n required n Coupler Controllers.
The dipswitch sets the Coupler Controller number representing its spot on the row and column of the matrix.
It might not seem that it is necessary to allocate a whole microprocessor to perform line supervision for the telephone lines, but I erred on the side of caution.
Line supervision means that you take a UVC-1 off-hook (close a switch) to place a call and place it on-hook (open a switch) to hang up. Pretty simple.
But then there are some more details: you can't take an individual line on-hook and off-hook too fast, or the Telco's (telephone company's) Central Office will interpret it as a dial pulse.
So the Coupler Controller kept track of such times for every line and enforced its own constraints, even if commanded to do something like that too quickly.
More stringent was the need to check for hangups; with loop-start telephone lines, a hangup might be a loss of loop current that lasts only tens of milliseconds; miss it, and you don't know that a party has hung up.
The Coupler Controller monitored each of the loop currents on the 24 lines it was responsible for.
It also monitored each coupler for incoming rings when the port was on-hook, a relatively slow process that presented no timing difficulties.
Dedicating an entire processor for line supervision functions turned out to be an invaluable circumstance when later on we needed to interface with Feature Group D loop reverse battery lines and for the next generation digital switch.
I claim no crystal ball powers, as I certainly didn't envision all of that -- but having a whole processor opened the door to more complicated needs down the road.
Tone Controller. The Telcro I had a single DTMF receiver and generator along with a single 8085 controller. It handled incoming calls one at a time: providing a "ready tone" prompt, collecting customer DTMF digits; and redialing using a dialtone detector and DTMF generator (all with associated timing constraints). We knew from the Telcro I experience, let alone larger switch sizes, that we needed the capability to do all of that for multiple lines simultaneously. Therefore I dedicated a microprocessor board to perform all of those tasks needed to actually process a single call setup. This Tone Controller performed all of the mostly user visible functions (sorry the board in the pic at right is partially unpopulated). Each board had its own tone generation and detection hardware. As much of those operations were made programmable as was reasonable. The DTMF generator, which consists of two super-imposed sine waves, was in actuality two programmable dividers that fed programmable bandpass filters. The processor could be programmed to generate DTMF outputs along with dial or ready tones, beeps, or whatever; any two audio frequency signals. The detection of network signals (primarily dial and ready tones) similarly was done with programmable center-frequency bandpass filters. Alas, DTMF reception was too formidable a task to be executed with that hardware, so an integrated DTMF receiver chip was used for that (identical to that of the Telcro I, my 8085 w/DTMF receiver repeater controller, and Message Converter projects).
A lot of the system's code (firmware) went into the Tone Controller, because it defined the customer and network interfaces. I re-used much that was in Telcro I, including the concept of dialing registers; pre-defined strings that gave the pattern of call placement rather than all of the specifics for a particular call. It had codes that referred to the input holding register which contained the user's input digit stream; so once a type of outgoing network call was determined (by the LCR computer), it merely selected one of those dialing registers. When equal access and Feature Group D lines came into existence, much was changed in the Tone Controller software along with some hardware additions.
The Tone Controllers were attached (through Audio Cards) to the switching matrix, on both the row and column sides.
In that fashion they could be connected on-the-fly to any incoming or outgoing phone line.
In practice, when a call came in, it was allocated (by the Master Controller) to the call; it stayed with that one process until the call was actually placed, when the user was connected to the outgoing line and the Tone Controller released from service.
The number of Tone Controllers could be varied (up to a maximum of one third of the number of incoming lines, set by the 16x16 matrix per 12x2 couplers).
Upon system reset, the Master Controller performed a poll to find out how many Tone Controllers were attached, and could be assigned duties.
This solved the predictable latency problem callers sometimes experienced with the Telcro I. We could also check the call record outputs to see how many of the Tone Controllers were actually being used, and adjust the installed numbers utilizing real statistics.
The dipswitch set the Tone Controller number for addressing purposes.
Master Controller. Each switching system had one Master Controller. It connected to the LCR computer (initially a TRS-80) via a serial port, and talked with all of the various slave controller boards through the backplane's parallel communication bus. All communications were initiated by the Master Controller; associated with each internal command was an expected response, which the slave immediately responded with to the Master Controller. To permit slave controllers to get the Master Controller's attention and initiate required actions, there were interrupt request lines on the backplane, as well. One common interrupt line indicated that calls were ringing in; another common interrupt line indicated that a call had hung up. Both of these emanated from the Coupler Controllers. There weren't too many of those boards in the system, so a single respective request line was fine for their entirety. Six separate interrupt request lines were strapped to the Tone Controllers; there might be a dozen or so of those per system, and with only two or three attached to a single request line, the Master Controller only had to poll those it knew were currently active and attached to the interrupting input to determine which one required attention. This typically occurred when a customer had completed the authorization/destination number input; and again finally when the call had been placed on an outgoing line. In between the two actions, the Master Controller submitted the information up the ladder to the LCR computer, which decided on the outgoing port and network method to transfer the call. The external communications protocols were modified and enhanced forms of those used in the Telcro I.
Each of the controllers was 8085/8155 based, with standard EPROMs holding the control program.
(And Intel got all of that microprocessor business from us, maybe because of my Intel benefactor when I was a student.)
The core processor section was identical for each controller board, with changes between boards resulting from differing I/O requirements and analog circuitry.
I laid out some of the circuit boards and Robin Becker WA2NYE (now N3IX) laid out others. These were all done by hand with stick-on tapes, etc.
I literally cut and taped negative images to duplicate the processor sections of the controllers. This was a time of whirlwind work for me; the Telcro II design process commenced in March, and our first switch was completed in August 1982.
That's a lot of hardware and many thousands of lines of software in between those two dates!
Though I might have mentally designed the Telcro II while still working on Telcro I.
First Telcro II constructed: 24-Path
There was no point in building a 12-path Telcro II switch, as we had outgrown the 12-path Telcro I unit at the Greenspring Valley Drive location the day we plugged it in. So I started with the next larger size: n = 2 for 24 paths (48 ports). Diagram above. You should see the overall diagrams for the larger sizes we later built, not sure where they are now!
Manufacturing and Personnel
I had been familiar with building small quantities of products. When I attempted to contact the main line component distributors, they showed no interest and made it difficult to place orders. So I just bought material from the hobbyist suppliers I was familiar with. The problem with that is that you don't always know what you're going to receive; they notoriously substitute different manufacturer's parts that are equivalent (the situation has improved somewhat today). One day Intel rep John Williams stopped in for a visit. He looked at our parts and there were some Japanese imitations there for the Intel CPU's, etc. I think that is the only time I had ever seen John's face get red. I was quite embarrassed, but told him of my plight. Right then and there he got on the telephone and called the right people at the various distributors. From then on we never had difficulty placing orders with them; in fact, they were extremely solicitous of our business.
For the very first units, I contracted hams and hobbyists I knew to stuff and solder the parts onto the circuit boards (in their respective kitchens, etc.). To get the onus of all of that effort off of me, we hired Mike Senate to run the manufacturing operation. He professionalized the process, incorporated ongoing back-and-forth planning with the suppliers, and had our boards stuffed commercially with wave-soldering machinery, etc. In the second half of 1982 we were beginning to really ramp up the production of Telcro II's.
It is difficult to remember everyone's name, but early on I hired Vince Weal KA3ALC (now K4JC) and Roland Slatkoff W3RUN as technicians. Roland took great pride in building the power supplies.
Mike brought Dan Dumler on board, who eventually led all field operations, including managing other installers, improving designs to make them easier to service, and more.
Later on we hired (names that come to mind): technicians Will Rotunno
Here is a short piece I wrote for our internal company wide newsletter describing the start-to-finish process of a Telcro II switch (page 3).
In October 1983 we had outgrown our 20 Gwynns Mill Court offices, and leased an additional building at 31 New Plant Court, less than a mile away, for our manufacturing operation (page 5). We researched various means to interconnect the telecommunications between the two buildings. Mike, Dan, and others surreptitiously ran an underground-rated multi-conductor cable on the bottom of a stream (I think during the dark of night) that ran past both buildings. Surely violating an unknown number of local ordinances, no one ever discovered our transgression (I wonder if it is still there, probably so!). They wired the two PBX systems together through the cable, plus implemented serial lines from the corporate VAX in our building to terminals in the Gwynns Mill Court building.
First 36-Path Telcro II
Second 36-Path Telcro II
First 72-Path Telcro II
First 144-Path Telcro II installation at one time
Telcro II Test Gear
We had also built some specialized debugging fixtures to test out the microprocessor controller cards. But it was mostly unnecessary, because I learned that if a board didn't work, after swapping the uP chips (those were socketed), a detailed visual inspection nearly always spotted a trace failure more quickly than an elaborate actual processor single-stepping session could.
Telcro II Deployment
More than 40 switching cabinets, accommodating 3000 telephone lines, were manufactured, installed, and maintained for the company. I've lost track, but we had switches in one or two dozen cities across the USA. Dick's model of building a customer base reselling SPRINT codes allowed us to get customers before ever picking a city location and installing a switch. Plus, we already had their calling statistics -- so we could engineer the network lines accordingly in advance of the cut-over. These Telcro II's comprised the complete communications network for Telesaver, and at the peak produced approximately $24 million in annualized revenues through their use.
Dick hired Bill Berg to write the BASIC least cost routing (LCR) control program for the Telcro II switch -- he also handled all of the other programming for the TRS-80's sprinkled throughout Telesaver. Dick also hired Robbie Trainer, a local Reisterstown lad, to help out with those tasks. Somehow or other Robbie was also familiar with telephony, which was a bonus. He really was a jack-of-all-trades, though we used him for software. Robbie ended up fine-tuning Bill's Telcro II control code to squeeze every last capability out of the overtaxed TRS-80. We used a BASIC compiler, not an interpreter. Robbie's code poked assembly language snippets into unused buffer space, and employed all sorts of other tricks to get it to properly handle our 72-path switches in realtime. He also was the point man in selecting TRS-80 peripherals and software. While Radio Shack offered its TRSDOS operating system, I think we used DDOS for the switches and LDOS for the development platform. There must have been some advantage to those alternative O/S suppliers. We added external 10 and 20 MB hard disk drives to the machines.
At some point one or two others replaced Bill Berg to handle the general corporate computing needs. I think that there was an intermediate DEC machine immediately after our widespread
Hal brought Brian Tenberg, Liza ____, and perhaps others in to handle programming. They did well. It took a special skill set to deal with Dick (I don't necessarily mean that derogatorily, but he could be quite demanding and more at times) -- and Hal had it. Hal's department was separate from mine; with regard to the switches, they handled the billing process (which is a significant part of the business) using data files transferred from the switches, but had nothing to do with the realtime LCR computing done at the time with the Radio Shack TRS-80's attached to the switches. That was for Robbie and me.
Here is a diagram I drew up depicting the combination of various TRS-80's, the VAX, and data flow in this time period (1983-1984).
File transfers were done with 5.25 inch floppy disks, that's what the little squares I drew are supposed to look like.
To collect data from the various switches, we had personnel on the scene pull the rawdata records from the switch computer onto floppies through a menu.
We received daily overnight packages containing them (Airborne Express did a good business with us!).
This reminds me of the question supposedly posed by an un-named college professor: "Q: What is the highest bandwidth data transfer mechanism? A: a tractor-trailer filled with video tapes on the interstate."
Of course we knew that this data transfer mechanism had to be modernized. But the TRS-80's were doing all they could, they had single-user O/S's, and commonplace modems were 300 bps -- although 1200, 2400, and even 4800 bps models were coming out.
System III Software
Language. In 1983 it wasn't quite obvious what language we should be working with. I narrowed the choice down to C and PASCAL. I was an EE, not a Computer Science major. So I took an afternoon off and visited the JHU campus where I discussed the issue with a professor or two. It came down to this: C was an up-and-coming language, and the preference for many young programmers. It was also extremely easy to write elaborate but confusing code with it. Runtime errors could crop up that were not detected at compile time. PASCAL was older and more established. Considered boring and old-hat. But it had extensive type-checking, would complain inordinately about mismatched datatypes, etc. The impression I got, right or wrong, was that once you managed to get a PASCAL program working, it would be rock solid as compared to a C program. I was extremely concerned about my team writing understandable code and the ability for programmers to pick up each other's code. I tried to think more like a manager than a code writer. More important than anything else was the reliability of the realtime application. I probably went against the grain and picked PASCAL (laugh if you like). I had never written a line of code in that language.
We bought an Intel development system. Our software (except for the LCR control program) was to run on the Intel SBC's and the VAX, so we bought PASCAL compilers for each. There were a few differences between the two, but once we worked them out we could easily write the code on the VAX and port it to the Intel boards for the turnkey system operation. Robbie found that some of the realtime control was better handled with Intel's PL/M language for the switch control software, so he wrote some of the lower level functions in PL/M (none of which needed to be put on the VAX). Guy ended up doing likewise for the parallel communications bus.
The Team. We needed to write a lot of software from scratch. The least cost routing switch controller program, certainly. But also all of the supporting software: customer database (authorization codes, etc.), call routing preparation, report generation, and billing software. Yes, billing, too. By then we had planned to sell our switches outright in addition to using them for our own network, and we wanted a complete turnkey system that handled everything. I hired Chris Mengel (JHU) and Guy Therien (Towson University, above center photo). Robbie worked on the control software, Chris started with the customer database software, and Guy began with the routing and communications software. After a period, Chris left to move to New York to help in his family's fish(?) business. I hired Andy McCasker (JHU) as his replacement. However, Chris had gotten a good amount completed with the authorization codes program, so I took over finishing his task after he departed (so I had to learn PASCAL myself!). I think Andy worked primarily on call search and report generation software. Tim Tarrants (photo above right) had worked in our network department, and he joined our team later on. At first I had him work out routing and billing structures that could match any conceivable vendor requirement. Tim was the most methodical person I think I'd ever met. When we eventually cut over to the System III software, I made him our Quality Control person. Any code change had to be tested and released by him (including mine). We all griped that he was taking too long to approve our revisions and that was exactly what I wanted.
There was some (good natured, I hope) competition between my team and Hal's group. I vaguely recall some Trojan software exploits in order to "own" the VAX. But they didn't have too much free time on their hands. They were salaried, and I told them I didn't care what hours they worked as long as the programs got written. Perhaps the other employees in the building who saw them stroll in wearing sweats in the afternoon thought they weren't actually working. But the others didn't necessarily know that they had been burning the midnight oil with their programming efforts. It reminded me of the various scenes described in Tracy Kidder's The Soul of a New Machine, with pizza boxes piled up in the corridors, etc. But upon hiring, I had also warned that there would come times when they'd be needed no matter what. One instance when we were working at the Columbia switch, Guy turned to me and said quite seriously, "This is one of those times, isn't it?"
I was heavily influenced by Frederick Brooke's writings in his monumental The Mythical Man-Month text on software engineering. Not that our project was anything like the size of his team that wrote OS/360. We had weekly meetings where we reviewed the status of each piece, and mostly discussed changes that could impact the timeline and other team members. I had created a roadmap, but if anyone in the group came up with a better plan, they knew that it would be put into action immediately. Which is an unlikely scenario for a just-graduated programmer at most larger establishments. The young crew didn't get paid that highly, but they were writing code from scratch that actually got deployed -- and they could see it on the various video screens in the office, or just by placing a telephone call and hearing it go through. That also put tremendous pressure on them to get it right -- their code impacted the success of the company as a whole.
But it was a fun and highly energetic time as well. These fellows had previously written mostly academic assignment types of programs. Which didn't have to deal with invalid user inputs, unexpected responses, etc. Of course our code had to be fully protected and bulletproof. I had found a few input sequences which would "break" the compiler's code at runtime -- and developed a tiny library of routines which replaced the more normal I/O functions with safe versions. I (perhaps cruelly) entertained myself by asking successively the newest team member if his code was crashproof. And being the young, optimistic, and top-of-the-class types that they were, I usually got a positive affirmation that the code was perfect. When I strolled to their keyboards and crashed their programs with two or three keystrokes, the resultant incredulity was a scene to behold. After letting each stew for ten minutes I came back and gave them the fixes. But it was an exercise well worth performing because it altered the mindset. And it was quite satisfying when on occasion I would walk past a cubicle and overhear the previously newest team member playing the same trick on the newest member! I didn't have to utter a word.
I also encouraged my programmers to actually use the software they had written. Since I had taken over the authorization code application from Chris (which did end up with lots of new things, especially after Equal Access), I spent some time in our Codes Department. Truly taking a day -- sitting in their chairs at their terminals and doing their work -- using my software in the real world illuminated the fact that maybe my "software engineer" thinking didn't reflect the users' needs quite as much as I thought. Sometimes end users don't know enough about software development to even ask for things that we could easily implement. And they had gotten used to being told many times that their requests were only dreams.
Our turnkey System III software was more than a simple or generic type of software package. We had witnessed countless times when Telesaver management and Operations staff went to Hal's group requesting a special report, graph, analysis, etc. The request was put into the hopper and it took a while to be satisfied. This isn't a knock on those VAX programmers -- that was the type of environment that software platform offered. We swore that we wouldn't produce software that let anyone pester us later on for what we condescendingly viewed as trivial modifications. Instead, every single aspect of the user interface was made as configurable as we could imagine. That is, configurable by the end user himself. Without a software change from us. Certainly this made it quite a bit more difficult. This was especially evident in the call search, report generation, and billing software sections. Template types of files could be created with a standard text editor which defined those applications. And it all worked.
System III Hardware
Dan Dumler worked out all of the physical hardware construction, with rack panels and special brackets made up that permitted the drives to be inserted and removed from the front of the cabinet. He also designed a Power Cart that served both the Computer Cabinet and the Telcro switches themselves. We needed to provide backup power for the case of AC mains power loss. With the TRS-80's, we had little choice but to put "UPS's" on the 120 VAC input to the computer. We installed Triplite SB-1000's; these really weren't UPS's in the truest sense; they passed the 120 VAC directly through until it disappeared; then activated a square wave inverter to produce a manufactured AC signal to drive the load. There was some switchover time, and they worked adequately. The power supplies inside the Telcro II's had very large capacitors added to let them ride through the switchover time. Now that we had the SBC's instead of a desktop computer to run the switches, we constructed a superior system.
Initial usage. We had sold a Telcro II/System III package to a long distance reseller in Virginia Beach, but we were still in the process of finalizing the software. This was prior to cutting over our Columbia switch (which had a large customer base and lots of traffic). Robbie and I were en route to BWI airport to fly down to Virginia Beach (the installation crew had already driven the equipment down in the Telesaver truck) with the latest software versions. For some reason we needed to stop on the way at the Columbia switch, and we were tight for time when we got to BWI. Robbie was amazed when I parked in the hourly lot (I wasn't a big spender) and asked "isn't that going to cost quite a lot?" My response was that it would be a lot less than the $1000/day penalty that was in our sales contract for delivering the switching system late. (I have no one to blame but myself for that condition, Joel sold it but I approved it.) Turned out that we missed the flight anyway trying to get Winchester hard disk drives through security. So I moved my car to long term parking and we caught the next flight out. Robbie liked to tell the story of how my head bobbed in a circle on the short flight -- I insisted that I was awake, but probably not! Guy, Robbie, and I worked at that location for a day or two or three -- when we left, it was operational but not tuned to be nearly as speedy as it ought to have been. The pictures of those two farther above were taken during that excursion in Virginia Beach, which explains the grim expressions on their faces -- we were under the gun to get it all working. I don't remember what the correction was, but a few months later we cut over Columbia with its high traffic. Which means that we had fully corrected whatever was deficient.
Quik Call 2000
Before equal access, all OCC's and long distance resellers were at a distinct disadvantage compared to AT&T: customers had to dial all those numbers.
AT&T users direct distance dialed simply by picking up the phone, dialing "1" followed by the 10-digit terminating number. Nothing more.
Telesaver customers had to: dial a
There were many autodialers on the market (such as the Demon Dialer). Most of them were single-line devices and were pretty simple: take the phone off-hook, enter a special digit or two, and the unit would draw dialtone, dial the carrier's local access number, wait for ready tone, and enter the authorization code. At that point the user was directly connected through to the switch which was waiting for the destination number to be able to proceed with placing the call. Many of them could also store frequently used terminating numbers in memory so that they could be quickly dialed with a few buttons (memory or speed dialer). There were a few problems with these simpler autodialers: some OCC's had the digit entry in a different order, so that method wouldn't work; the user still had to listen to what was happening in order to know when to dial the terminating number; and for carriers like Telesaver, which offered optional accounting codes (used purely for billing breakdown), those had to be tacked on at the end requiring even more user concentration.
MetroTel Corp. came out with their Quik Call 240 and they were making the rounds marketing it. They showed up at Telesaver's offices and were pushing us to bulk purchase them in order for us to give or sell them to our customers. We did like it. Its architecture was simultaneously a blessing and a curse: this unit could service multiple lines. The main box (above left) could handle one line; attach from one to three expansion modules (above right), and it could handle 2-24 telephone lines. Having a single unit handling all of those lines was a plus with regard to the cost and programming setup operation. Engineers know that nothing is free, and in this case that means that the Quik Call could actually be used to dial on only one line at a time. Take a line off-hook, enter *, and if no one else were using it at that instant, you got its attention; otherwise, you waited and it would respond to your request as soon as it could. That's the nature of the beast, the same as having the equivalent of one Tone Controller in the Telcro I. The "240" in the name referred to how many speed dial numbers could be stored. Storage of individual numbers wasn't all that important to Telesaver -- we mainly needed to equalize the playing field between ourselves and AT&T's direct distance dialing. But the unit mostly operated in the same fashion as all of the other autodialers on the market: it handed the call over to the user to finish the call.
The Quik Call ran off of a Z-80 microprocessor, an EPROM, a battery-backed-up CMOS RAM for memory storage, a DTMF receiver, and a DTMF generator. The engineer in me saw the opportunity to re-write its code in order to add the functions we preferred. MetroTel and Telesaver made an agreement: they would provide the documentation, I would rewrite its control program, Telesaver would buy lots of units with the revised mode of operation, and MetroTel could sell our firmware version to other customers as well (with some royalty payments back to us).
I think I reviewed the code and typical of many programmers, discarded it and started fresh (over 3000 lines, prepared on my MAXI micro). I released the final software version in May 1983, and renamed the unit Quik Call 2000. It didn't store 2000 phone numbers, I just thought 2000 was forward-looking to the next millennium. The main difference was that my code made the Quik Call a true store-and-forward unit: the device essentially collected all of the user information and put it back together in whatever order the carrier required for redialing. This included the optional accounting code. The altered unit worked fine and many of our customers used them. The curse I mentioned above refers to getting customers to be willing to wait for its attention when more than one person in the business tried to make a call at the same time. Nothing the software could do about that hardware restriction! Page 1 of this newsletter mentions the new dialer.
The Quik Call episode was my introduction to MetroTel's president, Venerando Indelicato; later on we enjoyed a productive business relationship (RTS-1, plus they were the initial marketers for my ARONTS product).
I think I went a little overboard with the Quik Call's modes of operation; it's a little too much "engineer" oriented with regard to configuration. Once configured for a particular operating mode, however, it was pretty simple to use given a multi-user shared environment. But surely I was the only person to ever make use of the Morse code number playback function! I doubt anyone ever realized that the "secret" factory-programmed code used to configure it was actually the largest five-digit prime number. Here is my instruction manual (written on the MAXI micro and printed on the Dura Mach 10), and here is MetroTel's simpler version. I don't suppose it's a good sign when a vendor decides to rewrite one's manual. Still, I like the user flow diagrams on pages 14-17 of my version.
When AT&T was ordered to divest itself of its local operating companies and provide "equal" access capabilities to all long distance carriers, it was an opportunity for alternative carriers like Telesaver to move into the mainstream. It was also an "opportunity" to work around the clock to build equipment which could interface with the BOC (Bell Operating Company) line interfaces! Prior to equal access, our switches were connected to customers more or less in the same way as any office telephone system. Once we answered an incoming call, Bell was out of the picture; what followed was just a voice call as far as they were concerned. Which meant that it was up to us to generate a "ready" tone to prompt our customer to enter (with DTMF digits) the authorization code, destination telephone number, and optional accounting code; and for the switch to receive that information and use it as required. AT&T customers, of course, merely direct distance dialed the destination number (1+); there was no other info to send, as the Telephone Company already knew the subscriber's telephone number and could bill accordingly. Equal Access meant that all long distance carriers could do likewise. Easy to say, more difficult to do.
To achieve equal access, we could no longer use standard business lines for incoming calls. An entirely new set of technical protocols were devised to interface with the carriers.
This permitted the switch to receive both the originating and destination telephone numbers from the network, invisibly from the customer.
There were very many different types of incoming lines to choose from. Our existing (in place) switches were all two-wire.
The simplest type of two-wire line available which could be used with the new Feature Group D type of line was two-wire Loop Reverse Battery.
So I designed and we built large quantities of loop reverse battery linecards to be substituted for the UVC-1's previously used (we still needed those for the outgoing lines).
That wasn't so big of a task. Shown at right, it was less expensive to incorporate a relay than use semiconductors; which I did very reluctantly -- prior to that one relay,
the entire Telcro II was completely solid-state.
The biggest difference to handle equal access was the signaling method: MF (multi-frequency) tones from the Telco's Central Office (CO) instead of DTMF tones from the customer. There were other complications, like handling wink acknowledgement handshakes, etc. But MF tone detection was a major change.
The Telcro II's Tone Controllers as they were could generate MF tones, but not detect them. Too bad that that was precisely the opposite of what we needed to accept incoming calls from customers via Feature Group D lines. I designed an add-on board for the existing Tone Controllers to permit MF tone detection (I made them programmable for any tones, but configured the filters under software for MF frequencies). The board was oddly shaped to plug onto a (new) connector which we retrofitted the Tone Controllers with. At left is a Tone Controller with the MF detection board. I think Dan Dumler might have done the circuit board layout. We had many switches in the field, and we wanted to minimize the alterations required to transition to equal access. Certainly we could have built a new Tone Controller from scratch to handle its new responsibilities, but that would have entailed more work and expense. It also wasn't necessary for all of the Tone Controllers to be equipped with MF detection because that operation was only required for the very first few seconds for each incoming call while data was received from the CO; the remainder of the call (which might include receiving optional accounting codes and which always included waiting for outgoing dialtone and re-dialing the destination number) only needed the simpler Tone Controllers. So I stole one of the interrupt request lines used for the Tone Controller to Master Controller alert and dedicated it to handling MF detection only. In our switches, only some of the Tone Controllers had the add-on board; upon power-up, when the Master Controller polled the Tone Controllers, they now indicated whether they could detect MF signals or not.
Designing, testing, and building the MF receivers was a certain amount of work; but the most significant workload was modifying the Telcro II firmware to handle all of this new stuff. I worked a crazy amount of hours on that revised firmware. Which was different from the time period when I had written the original Telcro II firmware: back then I was mostly working alone and the company only had a few employees. By 1984 most of my time was devoted to interacting with all of the employees, management, etc. I think I ended up writing most of the code off-hours when there weren't any interruptions. It was exhausting. Passing it off to somebody else would have taken far longer than doing it myself. (Near crunch-time I took no telephone calls and shut my office door with a note posted that said something like "Do not enter unless there's a nuclear attack or you are a beautiful woman." It worked...)
One minor detail: there were no Feature Group D lines available to check out all of these hardware and software changes on!!! All I had was a (gigantic) book of specifications. I don't like to build a big system or change a system without incremental verification (which I harp on with my students); but there was no choice here. So, while I am egotistic and believe in my hardware and software skills, I don't know how much money I would have been willing to bet that this entire equal access equipped switch would work once the new lines became available. I think it was in July 1984 that AT&T set up the first Feature Group D test facility in some town in West Virginia. Mind you, these were the only equal access lines in the world. Vendors were invited to schedule a slot to attach their equipment, try it, and debug it if it didn't work. We signed up, and I think we were allocated one hour. My crew loaded me and all the equipment I could think of that we might need into a van (TRS-80, eprom burner, scopes, ...), and drove me there. I really didn't know too much of what was going on, I had barely slept in the preceding weeks. We had an actual deadline to be ready for the West Virginia test, and of course I'd hear it from Dick et. al. if our switches could not handle equal access when the lines became available in our switch areas. I imagined all sorts of reasons why my modifications would not work. I still suffer from this "know too much" malady: having thousands of lines of assembly code, hardware modifications, and an uncountable number of pages of specifications spinning in my head, it was very easy to imagine something going wrong. After all, if any one of those elements were incorrect the call would not go through.
Upon arrival at the West Virginia test location, we sat quietly and watched the vendors in front of our time slot attach their gear. Most of it did not work. When our appointment time came, I feared the worst. Okay, we plug in, one-plus dial a call -- and the call doesn't work. What to do? Simple things first. The two-wire loop reverse battery interface has precisely three wires: Tip, Ring, and Ground. I reversed Tip and Ring and tried again. Voila -- the call goes through!!! I cannot relate the resultant relief. I finally got a full night's sleep in months. (They had the lines backwards, not me.)
I'm not 100% certain, but I don't think that the TRS-80 LCR software could handle the equal access changes; but we cut over to the System III software in August 1984, and I believe that that was when we turned up the Telcro II's which handled equal access. This time period was a bit more complicated than it might seem, because equal access and Feature Group D was not instantly available nationwide; there was a gradual introduction over many months when various exchanges were activated. We had both loop reverse battery cards for the equal access lines and UVC-1's for those customers which did not yet have equal access available in their calling areas on the switches simultaneously. Months were spent turning up equal access in the various locations. Quite often it would not work at first. But this interface was as new to the technicians at the Telco CO's as it was for us. Eventually Dan and I learned that if it didn't work, just try reversing Tip and Ring; if that didn't fix the problem, double check the earth ground. Dan learned what magic words he had to tell the Telco CO techs he was usually on the phone with to fix their own problems. It took a long time for me to lose my internal doubts, as every time something didn't operate properly I imagined many reasons that were my fault. But in practice it always came down to those three wires.
Beyond the technical experience, in this day and age it is impossible to explain how it felt for us to offer 1+ dialing. Nobody except The Phone Company had ever been able to offer that in all of our lifetimes.
Quite a thrill to be able to pick up a phone, direct dial a call, and have it go through our switch to the destination without another digit dialed.
We had become The Phone Company!
Telesaver wasn't the only reseller with equal access equipment challenges. Every other carrier was in the same predicament (I'm referring to the companies with small switches, not the ones with giant switches like MCI and SPRINT). It would take a relatively long time for the various manufacturers to upgrade their equipment to handle equal access. Our switch marketing department found this small niche which we could fill for a while: converter equipment. We simply took our Feature Group D equipped Telcro II switching modules and sold them as Equal Access Server Extender Equipment (E.A.S.E.E.). There was no need for an LCR computer -- I added some nonvolatile RAM to the Master Controller to store customer telephone numbers and wrote some more firmware. E.A.S.E.E. converted the MF information into DTMF digits that the customer's existing switch could relate to. A drop-in solution for them. It really was a waste of equipment. This was a full-blown switch relegated a menial task. To me, it was like a blind person buying a high definition television set in order to listen to the evening news. But there was a need, we had gear to solve it, and our company was in trouble financially. So we sold quite a few units. There's an announcement on page 3 in this newsletter issue.
We were building Telcro II switches like crazy, and had maxed out their size with as many as three 72-path units sitting side-by-side at the larger switching centers. I began the design of our next generation of switching systems in mid 1983: the Telcro III. Telcro III was a digital switch, moving beyond the analog switching mechanism of its predecessors. Other than the method of switching calls, it otherwise was identical to the Telcro II -- using the same Controller boards (albeit with considerable firmware revamping).
I managed to map the basic architecture of Telcro II directly into Telcro III's digital format.
The underlying digitized voice signals were carried on 16 PCM (pulse code modulation) highways.
Each PCM highway contained 32 voice channels (DS0, 64 Kbps each) for a total highway speed of 2.048 Mbps.
This was the standard format for the European T1 equivalent. Of the 32 voice channels on each highway -- or timeslots -- I allocated 24 as switched telephone calls, and 8 as auxiliary audio channels.
The 24 telephone call timeslots represented Side 1 plus Side 2 -- each 12 voice lines -- of the Telcro II. Those were the same as two UVC-1 coupler cages (incoming plus outgoing).
The 8 audio channels were equivalent to the 4 audio cards each on Side 1 and Side 2 on Telcro II which connected to Tone Controllers.
On Telcro II the 4 pairs of Audio channels were paralleled because it was only possible to connect a row to a column. This was unnecessary on the digital switch, because any timeslot can be routed to any other PCM highway timeslot.
As n spanned from 1 through 16 on Telcro III, there simply were n PCM highways. With the exact same 24xn ports as Telcro II.
The overall sizing and architecture was identical between the two generations, which made it easy to retain the same 8085 controller boards.
We also were able to interface the Telcro III with the System III software because at the high level (once you looked past the internal switching mechanism), there was no distinction between Telcro II and III.
While the two architectures were the same, the practical distinction was that it was indeed possible to construct an n=16 (384 port) Telcro III.
The Telcro III photo at left has the microprocessor controllers removed, and isn't really in a presentable form.
The top cage can house 24 Audio Cards (three are inserted); the two cages beneath that can hold 24 line cards each; and the cage below those is for the 8085 controllers.
I went with taller and wider (24 inch instead of 19 inch) standard rack cabinets; that made it possible to fit a 192-path switch (with analog telephone line interfaces) in two cabinets.
The new things in Telcro III were its Switch Card (at right) and the various line cards. Every Telcro III would contain but a single Switch Card. It connected to up to 16 PCM highways, containing 16x32=512 timeslots. The Switch Card performed timeslot interchange between those 512 positions, effectively switching the 512 channels. The architectural number n reflected the number of PCM highways attached to the Switch Card. The elaborate ribbon cabling needed to create an nxn square matrix on the Telcro II was eliminated, with but a single connection between a linecard cage (housing 24 linecards) and the Switch Card. Telcro III's one Switch Card replaced 256 of Telcro II's switch cards.
The backplanes and ribbon cabling on Telcro II only carried audio signals (and 10K/s controller communications).
Telcro III's PCM highways were 2.048 Mbps, and while that might not sound too high, I was quite concerned about signal integrity.
Again these cables were going to span both cages and cabinets. I chose balanced line driver and receiver integrated circuits intended to drive long cables to interface the highways to the backplanes and ribbon cables.
These interface chips had a lot of voltage overhead to combat line losses, and the balanced configuration inherently protects from signal crosstalk and interference.
Maybe that conversion would have turned out to be unnecessary, but I didn't want to take a chance and possibly need to redesign the boards later on when we built the two-cabinet switches.
The PCM highway transceivers (also on the linecards) performed flawlessly, as did the Switch Card itself.
These linecards had to include a two-to-four-wire hybrid function, and of course they had to convert from the analog realm to the digital. Most of that work was done by a new AMD AM7901 SLAC (subscriber line audio circuit) chip. That one codec sampled, digitized, and placed the signal onto a specified timeslot on the PCM highway. In fact it would have been possible to construct a 48-port digital switch even without a Switch Card, because the 7901 let you assign timeslots freely on two highways. But that wasn't a consideration for us, we surely wanted larger port sizes than 48 -- so we'd need a PCM highway interchanger (the Switch Card).
The AMD chip was an amazing part for its time, incorporating internal digital signal processing to accomplish some of its functions. Its biggest potential drawback was noise generation and susceptibility. Extreme care needed to be taken with circuit board layout to minimize what would be perceived as background noise. AMD had a reference board they loaned us with ground planes to show that it was possible to build a card with a reasonable noise level if done precisely right.
In retrospect, I probably put more hardware on the 2-wire linecard than was really necessary. I added configurable circuitry to accomplish frequency shaping, hybrid operation, gain and loss, etc., when the 7901 could have been asked to do some of that with its internal DSP capability. But at least my board did everything it was supposed to do!
We had circuit boards for both the 2-Wire Line and Audio Cards professionally prepared for us on a CAD workstation. This cost a pretty penny. In 1983 desktop PC's weren't powerful enough to support decent high resolution graphics and routing; very expensive workstations were, and those companies which had paid for them charged a lot for their use.
Other Analog Interface Cards. I had planned to make up several other analog linecards, such as 4-wire E&M and 2-wire station cards -- and to use some of those for inter-module trunking (System III software provided inter-module line lookahead, so calls could be passed from one switching module to another with the advance knowledge of which line types were available).
These were not difficult tasks given the completion of the
T1 Interface Card. I was very interested in getting a T1 interface for Telcro III as soon as possible. T1 lines are digital 4-wire circuits; each line (pair) provides 24 voice (DS0) channels on a 1.544 Mbps highway. This jibed perfectly within the Telcro III architecture: one T1 card would replace an entire cage of (24) 2-Wire Line Cards. I expected all new switch installations, as well as line expansions, to use this interface. Beyond reducing the size of the switch by 24 times, it eliminates analog-to-digital conversion, a hybrid, and provides for nearly a virtually end-to-end digital audio pathway. The line interface portion of the entire 384-port switch would consist of (16) T1 cards! I had fully completed the design of this card, and expected little problems with it. I don't think that we ever got to prototype and test it, however.
Controller Firmware. While the Telcro III architecture matched the Telcro II, the Switch Card naturally was controlled in a totally different fashion. I modified the existing Switch Controller's firmware to talk to the new timeslot interchanger. The impact on the rest of the system was nil; which was the reason to distribute control of the entire switching system from the very beginning. The Switch Controller accepted commands from the Master Controller in the same way it did for the Telcro II; it did whatever was needed to accomplish the timeslot control which made and broke virtual "crosspoint" connections.
The line cards and the Audio Card were also controlled in a completely different manner from the UVC-1's in the Telcro II. The AM7901's took a serial type of communications channel for quite a complex setup and control mechanism. I modified the existing Coupler Controller code to perform this communications task. Again, this difference was isolated from the rest of the system; the interprocessor communication was unchanged because the Coupler Controller handled the differences by itself. I made all of the 8085 controller firmware a superset of the Telcro II and III needs: upon powerup, the boards determined if they were in an analog or digital switch, and performed their tasks as needed for each.
A Little Help, Please. I hired Kodi Yazdanipour, a recent electrical engineering graduate from the University of Maryland College Park, to assist in the development of Telcro III. Kodi primarily prototyped my circuit designs and tested them. This included checking frequency response and so forth for these new cards. I recall him doing a lot of work on managing the noise floor with the 7901's. He probably made modifications based on his findings, and he was designing one of the analog line card variations on his own. I remember sending him to work at a vendor's site for a bit where they had a PC-based circuit board design program. I think he determined that it was too crude and coarse a system to be used for our purposes -- which is why we ended up contracting pcb layout out to a workstation equipped firm. I'm sure he worked on testing the overall system once we got it together. I was probably too hard on him. In my defense, I had a total of two engineers (he and I) and three programmers designing a state-of-the-art telecommunications system. And a company waiting for our newest designs to make it to the field.
Kodi and his family were religious refugees from the Ayatollah's Iranian revolution. His English was quite good, but nonetheless some of us teased him by repeating in his accent: "How eees the deeegeeetal sweeetch doing?" I hope he understood we weren't mocking him, just kidding around. Eventually his immigration status required an upgrade and I filed a lot of paperwork with the government to keep him in this country and in our employ. It was an arduous undertaking for him, even when it was finally approved: He was required to leave the soil of the USA and travel to any country which shared diplomatic relations with both the USA and Iran. Once he left, he technically was without re-entry papers; supposedly he could get new ones at the third country's embassy and return. He chose to go to Italy for the transaction. It was a bit scary when he left, because we really didn't know for certain that he could return. Should he be forced to go to Iran he would likely be murdered immediately. It all worked out and he did return, even with a bottle of fine Italian wine for me.
Telcro III Final Status
The digital switch was definitely working by September 1984; I have an article on page 3 of our newsletter here. The 2-Wire Line and Audio Cards were on circuit boards and had been commercially manufactured; these were the production boards. We had also laid out and built the new backplanes; had designed and built the physical card cages and connection system (Dan Dumler might have done those); and worked out all required cabling. The Switch Card was a prototype only, but it was not a difficult task to turn it into a producible pcb, too. For that matter, with only one such board per switching module, we could have constructed them as prototypes if we wished. The overall system was completely tested and worked just fine. There was nothing more to do to put together a 384-port switch with analog telephone line interfaces. Unlike with the Telcro II, there was nothing further to check to take it from n=1 to n=16; I had verified that the longest wiring we'd require to connect backplanes to the Switch Card operated without a hitch. We just needed to build more hardware and assemble it.
Unfortunately, the end of 1984 through 1985 and until the end of the business in 1986 were financially troublesome times for the company. We simply lacked the cash to move forward. So the one and only Telcro III sits in my basement today.
Sherry Berman (at right) worked for Joel on the marketing efforts. One winter when we had an exhibit at COMNET in Washington, Sherry came by my house in the morning so we could drive down to the DC Convention Center together. There was a little bit of snow on my road, and she couldn't navigate her car up my steep hill. In the era before cellphones, she just parked at the bottom and walked uphill to my house -- in heels. I have no idea how she managed that. Sherry was nonplused and we made our way to the show.
Joel worked on selling the Telcro II, EASEE, and preselling Telcro III. We kept trying to come up with variations which could be sold.
One was that of a building concentrator: intended for shared tenant services, the Telcro II's inputs were direct lines from various corporate offices in a high-rise; its outputs were a smaller number of long distance lines.
I don't think any of those were actually sold. Here are some of the
Vistacom eventually sold about $400,000 worth of equipment.
Management and Rogue's Gallery
All of us were aware -- but especially Dick -- that we needed to actively think about our managing tasks. Many of us were catapulted into running departments with no significant previous experience at that. We had expanded from three to over 100 employees over a two or three year time period, the headquarters was in two buildings, we had switches in a dozen or two cities spread out all across the country, and there were office and sales managers and representatives in many regions. We had executive meetings (probably weekly); of course we reviewed the corporate state, but at many of these Dick passed out articles or books on management techniques which he encouraged us to review and discuss. As if we all were not already overwhelmed with our day-to-day duties! He deserves credit for those efforts.
I might have been the only one who could get away with sleeping at times during those meetings. Sometimes I'd lay my head down and try to listen enough to detect any subject which impacted my area. I didn't really mean to, but occasionally the inevitable resulted (at least I don't snore). I did take the human resources area seriously, though. I even thought I should learn more about business and finance, and attempted to read a few accounting books; but every time I literally fell asleep.
Bob Chertkof (above center) was our Executive Vice President and internal legal counsel (page 1). I thought that sometimes his was the main voice of sanity. When VisiCalc was put on his TRS-80, he seemed to go berserk and was constantly printing very long spreadsheets with projections of the company's growth.
Yours truly (above right, page 2) was Telesaver's Director of Research and Development. I kept rejecting the title of Vice President, an emotional reaction to the memory of my Sonaphone episode regarding titles. At one point a clerk came over to our building with a box of new business cards for me with that unaccepted title change -- and I sent him away with his box. When we created Vistacom I did accept the title of President for that subsidiary, but only after Dick actually granted me the authority to do some things which he was quite against (and I did). Whatever we called ourselves, I was mostly concerned with getting our designs completed and functioning in the field.
To Mike's right is Greg Jones (page 3), who ran Telesaver Marketing. Mike Senate (page 1) is next, who handled all of the operational activities in our manufacturing half of the company. Above right is Joel Maloff (page 2), who created and ran Switch Marketing.
To Christie's right are Denise Beavin (now Dumler) and Deborah Baylin. Denise worked for Barbara in Codes, and I spent a fair amount of time over there tending first to the TRS-80 codes programming, and then our System III implementation. Deborah (page 1) was our Communications Director. She wrote Telesaver's newsletter, the Telesaver Exchange. Perhaps due to my own editing experiences, I very much appreciate now all of her issues: we think the purpose of such newsletters is to inform for a short period of time; but in later years they become the only reliable historical record of earlier times. I've made use of them constructing this webpage 25 years after the fact. Thanks, Deborah!
Above right are Teresa Simpson and Tim Tarrants. Teresa came over quite early from Virginia with Walt Anderson; she worked with the outside carrier vendors we connected our switches to in the Network Department. In the shot with her is Tim Tarrants, who also worked in Network, and later joined my software group.
I don't seem to have photos of a number of people I would have expected to. Oh well.
Deborah Baylin was the editor of the company newsletter. Here are scanned versions of the issues I have:
I doubt that business experts would be too surprised when reviewing our trajectory. The rapid rise of Telesaver's long distance business along with that of Vistacom's manufacturing side looked quite promising. They both presented difficulties. We were making equipment sales in our Vistacom side, and the prices were high enough to be significant (low quantity but high price). The overhead and salaries were not that great for manufacturing as compared to the amount eventual sales delivered. These large purchases present fairly long leadtimes for the sales staff to nurture and bring in; plus, the industry was undergoing tremendous post-divestiture upheaval. Despite our attempts to separate the Telesaver and Vistacom businesses, the two were still quite intertwined and it was difficult to properly isolate the two financially to attribute expenses, etc. We definitely needed to bring more money in or the company would be lost.
Vistacom. I think it was in 1985 when we seriously began attempts to sell the technology we had developed outright to other firms. There were a number of quite seriously interested parties. We had meetings with technical and management representatives, and the legal teams were drafting technology transfer agreements. These potential deals had dollar figures in excess of a million bucks; a single completed transaction certainly could have carried Vistacom forward without difficulty.
In the meantime, we had no choice but to reduce expenses. Which meant laying employees off -- that is the nice way of saying we (I) had to fire people. The firings had nothing to do with competence, we simply could not meet payroll. I imagine that it is very trying to be fired from a job. It is also quite trying to have to fire people one had interviewed, hired, trained, and worked alongside with on a daily basis. Because we viewed the potential technology transfer deals as company-saving, while trimming down operational manufacturing staff to the bare minimum, we kept my small design staff as long as possible. Once they were gone I didn't see a good likelihood of achieving the big deal we needed. So for a while we struggled to make equipment sales and hoped for one of the big agreements to come to fruition.
Telesaver. On paper, the long distance business was profitable. But there are many details. Significant capital is needed to open remote sales offices, switching centers, and the like. But the greatest challenge was the phone lines themselves. These lines (attached to the switches) presented very large installation expenses, up-front costs, and long term contracts. We lost a lot of money in the resale business at times when the carriers were slow to deliver lines at promised dates -- meaning that our calls had to be placed over more expensive circuits while waiting for the lower cost facilities to become active.
Financing. All of these problems really came down to the standard conundrum of book profits versus cash flow. Dick had sold stock to shareholders upon Telesaver's inception. I don't remember the numbers, but the amount of money raised in stockholders equity was very low for an enterprise of our size. (In my opinion, while there are hundreds of decisions that might be questioned, I attribute the eventual downfall of the business primarily to undercapitalization.) So we pursued financing any way we could get it.
The resale business had a large amount of money coming in and going out every month (a sliver of which was our gross profit). We obtained bank loans based upon our receivables. The credit line was tied to the billing amount. Tiny burps in the monthly billings, or carrier failures, or any of a number of events could and did put us beyond our credit limit which had been stretched to the maximum. This was a period of time when Dick and the financial executives were constantly working with the banks to make it through the next payroll period.
Another avenue open to Telesaver was the sale/leaseback of switches. This is a fairly standard method of financing: Company A has a financing company purchase equipment from Company B; then Company A leases it from the finance company. Even though Company A and Company B were the same company in our case, a leasing company accepted our business; every switch we built and installed at a Telesaver switching location, the leasing company bought and leased back to us. It turned out that every switch we manufactured was a large source of cash for us, as it technically was sold outright and we got the cash immediately from its sale. This occurred prior to the Vistacom/Telesaver reorganization -- long before we had sold the switches outside of the company. I don't know how they came up with a sale price. I do remember my eyes bulged when I learned what it was.
The sale/leaseback arrangement was aboveboard, the leasing company knew the risk it was taking and was willing to provide the financing. They probably salivated at the interest rate they charged for the lease. But (at least in my mind, and maybe only in retrospect) this situation was quite different from the usual sale/leaseback arrangement. Typically, the equipment itself provides the collateral for the financier -- should the lessee fail to make payments, the leaser repossesses the gear and sells it on the open market to recoup its money. But this fallback depends on the equipment being saleable to outsiders. Theoretically, they could sell our switches to other resellers. But if Vistacom hadn't been successful enough in selling quantities of its switches, how is a finance company going to find buyers for a highly technological product produced by a probably defunct manufacturer?
By happenstance, I'm reading The History of MCI -- the Early Years as I write this. I am amazed at the similarity of our experiences and those of MCI. Certainly we were much smaller than them, and MCI pre-dated our company by several years. MCI used the same sale/leaseback strategy for its microwave transmission equipment to finance the company. In their case, at least they didn't manufacture it. But in reality, the only other potential buyer for that quantity of equipment was AT&T. And AT&T only bought from its subsidiary, Western Electric. So in fact, the collateral wasn't useful to the financing banks in their case, either.
After our companies failed, the leasing company did repossess the switches and apparently quickly discovered that they couldn't sell them for anything less than pennies on the dollar. So they figured they might as well try to use them in some manner in order to pay back their investment. They ran a building concentrator business for a while in the shared tenant facility market. They contracted with me to retrofit their switches for that operation from 1986 into 1988 (one batch ready to be shipped to California at right). The concentrator application didn't require LCR computers, and ran exclusively on the switch hardware and firmware itself. I forget how long they stayed in that business -- I hope that they managed to make some money in the process.
Back to the main resale business story: During the rise of Telesaver, Dick actually had offers on the table to purchase the company (I recall a solid one from MetroMedia). He was reluctant to do so and relinquish his control of the company (he and his wife owned something like 85% of the stock). Part of that was his fear that a new owner would primarily take the customer base and eventually liquidate the business at our Owings Mills campuses -- which would end most or all of the jobs. It is easy to claim in hindsight that he should have sold (while he could), but that isn't fair in my opinion.
By 1985, Dick was scrambling to save what he could of the Telesaver resale business, which employed most of the companies' staff. Good acquisition offers were long gone. He attempted to find a buyer that would keep the business more or less in the same operational mode we were in. It was clear by then that he and the shareholders wouldn't exit with a windfall. He really was just trying to save the jobs of the 100 or thereabouts employees we had, if possible. It seemed that that desire was met when he found a local group of investors (financiers) to sell the resale side (Telesaver, not Vistacom) to. I believe this was in March 1985.
All of the combined employees at Telesaver and Vistacom were in emotional distress for many months as the companies struggled. Our plight was no secret. When the deal went through that sold Telesaver, an audible sigh of relief emanated from those employed at our Gwynns Mill Court facility that housed the resale business. The New Plant Court building that primarily served Vistacom was still under pressure. There was a bit of a haughty attitude from the Telesaver side towards our side, because their jobs had been saved and ours hadn't been (at least not yet). Unfortunately that gloating was short-lived.
In what would appear to be a pre-ordained fate, all that could go wrong did go wrong. Barely a month after the deal that "saved" Telesaver was finalized, Maryland's Savings and Loan crisis hit. It turns out that some of the very same investors in the newly formed follow-on company (Mid Atlantic Telecommunications) that was previously Telesaver were the principals involved in the financial crisis, which included criminal indictments. These people were very well known and renowned members of the Baltimore financial and political community, and the revelations were shocking.
Poof! Overnight the fate of the former Telesaver employees was highly questionable. Now the Vistacom employees got to exhibit a slightly haughty attitude towards their former Telesaver friends.
Vistacom was in big trouble, and we were still struggling along in hopes of closing some large sales that could save us. But at least we still existed, and weren't owned by anyone under indictment.
Mid Atlantic sold the resale business to Capital Telecommunications Inc., an existing reseller based in York, PA that had been one of the buyers of Vistacom switches.
For a while the former Telesaver operated out of the Gwynns Mill Court building as a CTI location; eventually they closed that facility down and relocated some of those employees to York (I think by the end
Through the end of 1985 and the beginning of 1986 we tried to salvage one of those technology deals that would save Vistacom. They still appeared quite possible. I fired more and more people. Others, seeing the writing on the wall, found new jobs on their own and left our employ. By the end, what we had left was a mere skeleton of a once vibrant company. It became a chore personally to go into the office, where none of my friends were left -- when once it had been a fun and energizing place. After the last of my design crew was gone I didn't see any hope that we could cut a deal and reconstitute the company. I think it was in April 1986 that I tendered my resignation to Dick. That effectively ended Telesaver's manufacturing arm, Vistacom. The long distance resale side of Telesaver had already been lost.
We had created Telesaver out of nothingness, and it dissipated into the aether. Entropy had won out.
Telesaver, 1981-1986. I would guess that the average age at the companies was in the twenties.
It was a very exciting time for all of us -- we didn't know what our limits were, and took pride in accomplishing things they said "couldn't be done."
Many of the employees not only worked together, but socialized together as well.
(See also "A Family Business" on page 1.)
There were a considerable number of "attitude adjustment" sessions at local bars -- I mean, restaurants.
We believed we were in a special place and time. I do think that we were,
The world after Telesaver. Life moves on, and Telesaver did serve as a launch point for a number of its former employees -- some of which had no prior communications experience. Dick Goldman got involved in home security and smart houses (Intellitech, Home Systems Plus) and since 2003 has been the General Manager of the Pearlstone Conference & Retreat Center. Bob Chertkof formed a recruitment firm. Joel Maloff does telecom consulting. Dan Dumler was a longtime Vice President of Capital Telecommunications, Inc., and now does telecom consulting. His wife Denise manages a telecommunications department at T. Rowe Price (a long way from the Codes computer). Robbie Trainer and Guy Therien advanced through various software firms in the Baltimore/Washington corridor; eventually, Intel noticed Guy's rise in the iRMX-86 community and hired him, where he continues to move on up in various roles (named a prestigious Intel Fellow in 2017); Robbie is currently CTO at SatisFacts Research. Andy McCasker progressed through a number of companies and is currently CTO at Fishbowl. For a while Kodi Yazdanipour was a switch design engineer at the giant European manufacturing firm Alcatel; the last I heard he was Principal Engineer at Hyundai Electronics' Network Systems Division.
I'm sure there are very many other follow-up stories that I'm not aware of!
(I hope that I haven't hurt anyone's feelings in this tale, recounted mostly from memory. There were more people involved that don't readily come to mind. I bear no ill will towards any of my former fellow warriors and cherish our shared fight. The circumstances were as they were. REG9/2010)
All content Copyright 2019 IC Engineering, Inc. This webpage last updated: February 21, 2018