Personal Home Page | Business Home Page | Resume
Main Projects Page | Ham Radio Projects Page | Computer Projects Page | Project Chronology Page
Telesaver Projects
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.
UVC-1
So I began the design of a telephone switch beginning in the end of 1981.
A seemingly trivial but major part of the design process was the line card used to attach to the telephone lines.
We were past the Sonaphone era when direct connection was prohibited, but FCC part 68 type approval was needed for that electrical connection.
Typically, manufacturers had an entire product tested for FCC approval. This was fairly straightforward, but if any change at all was later made to the overall gear it was necessary to go through the entire process again to secure re-approval.
I knew that our switch was going to experience many changes in the near future and couldn't stomach the aggravation, expense, and delay to do that over and over.
Therefore the first aspect of the project was to come up with a card that could achieve FCC approval no matter what it was subsequently connected to.
This is more difficult because it had to "protect the network" from anything imaginable on its other end.
It was a great milestone when I got my UVC-1 (Universal Voice Coupler, at right) FCC approved as "fully protected voice circuitry" on March 30, 1982. (I submitted it to Maryland Electrical Testing in January 1982 to handle the test/approval process.)
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
Telcro I
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.
Dick found a furniture maker to build us a custom (wooden) housing -- I think it cost less than a standard rack cabinet, plus looked a lot nicer.
Two card cages held (12) UVC-1 couplers each for the fixed 24-port design.
The switching matrix consisted of (16) 4x4 analog crosspoint chips, providing a 16x16 non-blocking array.
There were no relays in the UVC-1 and no relays in the switching matrix, resulting in a completely solid state switch.
I used one 8085 microprocessor to control everything (2908 lines of assembly code). This does not include high level functions: we had a Radio Shack TRS-80 to handle that.
Dick contracted someone he knew to write the BASIC program on the
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!
Above is the Telcro I microprocessor board (left), switching matrix board (center), and interconnection/audio board (right).
Construction was wire-wrap (actually Slit-n-Wrap, which permitted daisy-chaining with a single continuous wire).
The three boards and the two coupler cages were interconnected with ribbon cable.
The 16x16 switching matrix used 12x12 of the array for the telephone lines; the remaining 4 ports on each side connected to a DTMF generator, DTMF receiver, and busy signal and ready tone generators.
Because it had only one DTMF receiver and one DTMF generator, it could handle one customer call setup at a time.
Once a call was connected, the parties remained connected through the switching matrix without the need for any DTMF activity -- so it could support 12 simultaneous customer calls up at a time.
This configuration worked adequately enough for the evening and night-time calls, when the average call duration was lengthy -- statistically call setups didn't happen all that frequently.
(The original specification was for primarily residential customers.)
But during the daytime, business calls tend to last a briefer time and there are many non-answered calls -- both of which increase the demand for call setup compared to the number of available ports.
The symptom was that sometimes incoming callers would have to wait a while for their call to be answered, as Telcro wouldn't answer queued calls until the sole DTMF handler was released from a previous caller.
We learned what we needed to know from the Telcro I. It was never designed to be more than a one-of-a-kind initial foray.
Here is the Telcro I documentation. I don't know what its eventual fate was, probably a landfill somewhere. I would have liked to include it among the bevy of ancient projects stored in my basement.
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.
Telcro II
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.
Subsystems
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.
RCA and Raytheon had crosspoint chips which used silicon controlled rectifiers (SCR's).
Seemingly a strange switching mechanism, and truthfully unwieldy to control, they had one redeeming characteristic: on resistance under 10 ohms.
Each crosspoint consisted of a pair of SCR's. Now, in order to utilize an SCR, there must be
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.
The Switch Controller kept track of which crosspoints were connected in the array (it had a larger RAM chip for that purpose).
It accepted commands (from the Master Controller) to make and break specific connections.
Making a connection entailed turning on the appropriate current sink, addressing the proper Switch Card, and triggering the specific crosspoint on it.
While it never really came into play in the LCR algorithm, the hardware supported more than one connection between a row and a column (in other words, it could have implemented conference calls).
Breaking a connection entailed opening the current sink path from the switching array, and if more than one connection had previously been activated, re-connecting the remaining crosspoints on that current line.
The Switch Controller took care of these low level details so that the higher level controller only had to issue a single make or break crosspoint command.
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!
Above is the Telcro II unit -- Serial Number 1 -- completed in our laboratory and ready to ship out for installation in August 1982.
At left, Patti Margolis poses; center, the 24-path ribbon cabling (we neatened that up in later units); at right is the power supply.
The power supply provided an unregulated +8/+15/-15 VDC similar to those of
We also decided that a better location for the switch was Columbia, MD. We could get lines local to both Baltimore and Washington, which was good for customer access and Baltimore-Washington traffic.
We had opened a sales office on Wincopin Circle, so we ordered the lines and moved the first Telcro II there on August 30, 1982.
Mike Senate, Roland Slatkoff, Vince Weal, and Walt Anderson doing the moving in above photos.
Below, a smiling Marshall Sapperstein (page 1), who ran that office and sales for the region, welcomes us. He has been selling "Universal" service and needed the equipment to back it up;
Walt and Mike punching down the Telco wiring; and finally, some celebratory champagne!
Above is the 24-path unit installed. At right, Bill Berg puzzles over his TRS-80 code.
No slight to Bill -- I also spent many hours sitting there watching comm protocols flashing across the screen in search of bugs.
(Which reminded me of the time I had spent observing the repeater's voting system.)
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
With the 24-path unit behind us, we put together the biggest that could fit into a single cabinet:
the next larger size: n = 3 for 36 paths (72 ports).
We installed it at our Columbia location on September 22, 1982.
Marshall Sapperstein was happy once again -- he could fit more customers on the switch than with its 24-path predecessor.
We moved the 24-path unit from Columbia to Philadelphia three days later, opening our first out-of-town switching center.
Second 36-Path Telcro II
We built another 36 path unit (SN003) to upgrade the Philadelphia switch.
It was installed on October 30, 1982 by our mysterious Telesaver Installation Team.
Hard to identify the crew at left, but surely at right Dan is thinking "Why is he taking my picture instead of helping me lug this cabinet?"
Apparently we had not yet bought the Telesaver truck.
First 72-Path Telcro II
We kept using Columbia as our guinea pig -- erhhh... chosen one for new equipment installation because it was the closest, and had the greatest customer base.
Here we install the first 72-path (144 port) Telcro II there on December 6, 1982.
Again, a smiling Marshall Sapperstein contemplating more customer sales; more champagne with Jim Simpson, Will Rotunno, Mike Senate, Walt Anderson, and Dan Dumler in photo.
This n=6 design was a challenge, with 12 coupler cages, 6 Coupler Controllers, 36 switch cards, a 6-card Switch Controller, 23 Tone Controllers, and the one Master Controller.
We built it into two separate cabinets (which had nice backs to protect the internal wiring). The cables spanned across each with connectors to permit separation.
I silently drew a sigh of relief when the internal processor communications worked fine between individual cabinets, now in addition to the separate backplanes of earlier builds.
The rails holding the back card cages tilted out to gain access to the insides; the ribbon cabling (not shown here) in the back of the unit was a topological gem (I think Dan worked much of that out).
The celebratory cake back in the lab was justified, because this was the practical size limit for our Telcro II switches.
I think I'm covering up 72 "port" because while it provided 72 paths, it had 144 ports.
The crew was getting more professional with the need to cross-connect wiring for 144 telephone lines.
In little more than three month's time, we had built and installed 24-path, 36-path, and 72-path switches in Columbia.
In addition to putting switches in Philadelphia, Hazleton (PA), and San Francisco.
First 144-Path Telcro II installation at one time
The maximum real Telcro II size was 72-path, but we ran trunk lines between two 72-path switches which enabled each switch to be able to pass calls through to the other.
Primarily to get maximal utilization of expensive FX lines.
You can see how neatly they had managed to package the ribbon cabling in the rear of each cabinet pair by this time.
My photo album notes that this installation in Manhattan on October 8, 1983 was the first such install done at once.
We probably had already done the same thing in Columbia, but by expanding its existing 72-path unit.
Each pair of cabinets ran mostly independently, with their individual TRS-80 LCR computers.
Curt Cavey (above) and Bob Smith (below) preparing phone wiring.
On the bottom right are a bunch of the VFR-5050 amplifiers.
Dan Dumler also on the scene.
Telcro II Test Gear
Back at the lab... After constructing a switch, we needed to fully check it out before it left the premises.
We had a few different test configurations in order to test individual boards, cables, and systems.
They were different arrangements of the same Telcro II boards and controllers with specialized BASIC programs I wrote for the controlling TRS-80.
I can't quite remember what the cabinet in the leftmost shot above (and the zoomed center image) was for.
It might have been a UVC-1 linecard tester.
We did have some programs that utilized the quantity of input and output connections the Coupler Controllers offered to rotate one connection across a field of wiring,
checking for one closure in the set.
Above right is the cabinet we used to test the Switch Cards; it used 16 Tone Controllers, a Switch Controller, and a Master Controller.
It had to check every crosspoint connection in each Switch Card for its proper closure, but also for erroneous connections that would cause crosstalk in the finished switch.
I think it had a Tone Controller place a tone on a column line, and listened on every other column line and all the row lines; with one connection commanded, the tone should be detected on only one line.
It sequenced through each of the 256 crosspoints in each Switch Card, and it tested 16 Switch Cards at a time.
You can see them in the upper cage, and the Tone Controllers in the bottom cage.
Much of the testing in the lab was done by Tim Gayheart, on the right.
I had also written a suite of test programs that executed on the completed switches themselves (both in the lab and in the field).
The microprocessor controllers each had built-in self-test programs which were activated; plus the test software drew dialtone from every telephone line --
this checked both the phone lines themselves, plus the ability to make a crosspoint connection through the entire system to a Tone Controller.
That final test was a pretty complete checkout, although it couldn't fully test for shorts between crosspoints (which had already been pre-tested).
It was fun to run it in the field where we had multitudes of telephone lines, because it could test them all mostly simultaneously.
In the lab it had to perform a one-by-one sequence because we only provisioned a line or two for that purpose -- it checked everything out, but took a lot longer to run.
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.
Software
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 Reid, 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
So I worked on a plan we referred to as System III software (the Telcro I and II LCR programs running on TRS-80's were I and II).
This did not refer to the new Telcro III hardware under development -- the new software system was built to work with either Telcro II or III hardware.
The first thing we had to do was decide what the computing equipment would be to run the switches.
IBM had indeed come out with its PC by then. But in my mind that was little more than a souped-up TRS-80. It was meant for a home environment.
What we needed was an industrial process control computer.
Robbie (photo above left) and I reviewed three different candidates: Intel's Multibus I boards; some National boards; and I can't remember the third.
We were concerned with the capabilities of the hardware, of course. That included peripherals like disk controllers, clocks, etc.
We also wanted a range of boards so we could customize CPU computing power to various requirements as they arose.
But the software environment and packages available were critical elements in this selection phase.
We read the documentation and went to a few seminars (they really did want our business, we were viewed as the rapidly growing telecommunications company that we in fact were).
The two of us chose Intel SBC's (single board computers), with 8 inch floppy (they stored a whole megabyte) and 5 inch Winchester hard disk drives.
Since the Multibus was an open architecture, there were other firms offering compatible boards and peripherals which we took advantage of.
We selected Intel's iRMX-86 realtime operating system as the base -- what a relief after all of the strange stuff we did to get the TRS-80's to service the switches!
(I think we did this before bringing the others on, if my memory is inaccurate my apologies.)
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, RIP) 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.
We cut over to System III software in August 1984, 15 months after first investigating what to replace the TRS-80's with.
Here is a diagram I drew up depicting the combination of various Intel SBC's, the VAX, and data flow.
On page 5
here I give a progress report, and on page 5
here I describe the newly operational software in our newsletter.
For every member of the software team, this was the first full-time job after graduating. They each were something like 22 years old, and delivered a fully operational realtime telecommunications system, complete, in about a year's development time.
I was not surprised, they were very, very, sharp individuals -- I had interviewed countless applicants to put together this small group. I am still quite proud of their achievement.
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
The System III hardware consisted of the Intel SBC's, floppy and hard drives, power supply, and cabinetry.
The architectural design was similar to that employed with the 8085 microprocessors inside Telcro II.
Each switching module was attached to a single Module Call Processor (MCP) as shown in the
previous diagram.
We had two or three 72-path Telcro II units at more than one of our larger switch locations.
There was a separate Master Processor (MP) in addition to the MCP's.
They were all connected via a common parallel port communications bus (you can see the connecting ribbon cable in the pic at 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.
The Power Cart had a 120 VAC input switching power supply which charged gel cells configured in a series arrangement totaling 48 VDC.
The 48 VDC battery fed a switching power supply providing +5 VDC, +12 VDC,
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.
Equal Access
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!
E.A.S.E.E.
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.
Telcro III
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.
Two-Wire Line Card. The other major new part of Telcro III was its linecards.
I chose to design first the 2-wire loop/ground start linecard (above). While I believed that our future would definitely be purely digital Telco interfaces (T1), all of our Telcro II switching centers had 2-wire analog telephone lines attached.
So when we first rolled Telcro III's in to replace the Telcro II's, we would need interfaces for those lines.
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!
Audio Card. We also needed the equivalent of the Telcro II's Audio Card. While for that version all that was really needed was an audio coupling transformer,
with the digital switch every signal needed... digitization! This board was mostly a subset of the circuitry used on the 2-Wire Linecard, the AM7901 being the major element.
The Audio Card (shown above) provided a means to connect to the (existing) Tone Controllers.
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.
Switch Marketing
In addition to designing and building switches for Telesaver's use in its resale network, we had decided to sell the equipment outright to other resellers.
The directions of the two halves of the company were possibly veering apart. In June 1984 we split the original Telesaver into three companies:
Telesaver, the long distance reseller; Vistacom, the switch manufacturer; and Vista Technologies, a holding company.
(Described on page 1
here.)
We hired Joel Maloff to run Vistacom's marketing department. Among other methods, he had us showing our wares at exhibit booths at various industry shows.
In the above left photo, a Telcro II switching module is on the left and a System III computing cabinet is on the right.
The picture on the right displays some of the Telcro III circuit boards.
Show reports are on page 3
here and page 4
here.
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
sales brochures.
Vistacom eventually sold about $400,000 worth of equipment.
Management and Rogue's Gallery
Our founder and president Dick Goldman K2ZWF (above left) was perhaps the most creatively intelligent person I've known.
He was constantly thinking up new off-shoots for the business (for example, Videotex). Depending upon one's viewpoint that can be good or bad.
I tend to be more focused, but maybe a wider perspective is required to create a gigantic success story.
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.
Lenny Moskowitz (above left, page 1) was our Vice President of Human Resources, a gentle man.
To his right is Mike Metzger (page 1), the Controller.
He had had earlier businesses which marketed gizmos on late night television -- and we constantly kidded him about Ginsu knives.
Mike wasn't that big, but he was a real strongman.
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.
Barbara Peterson (above left, page 1) ran the New Accounts department. But we called it the Codes Department, because every customer was issued an authorization code which seemed to entail constant attendance (the codes were of course secret).
To Barbara's right is Christie Harmon, employee #2. She eventually moved up in our Finance Department.
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.
To the immediate right are Sibby Peterson and Guy Therien at one of the company parties.
To their right I've forced Andrea Bromberg to model our Telcro II unit, serial number 4, headed to Sacramento.
At the far right Dan Dumler works on the cross connect wiring at the Hazleton switching center.
I don't seem to have photos of a number of people I would have expected to. Oh well.
Telesaver Exchange
Deborah Baylin was the editor of the company newsletter. Here are scanned versions of the issues I have:
- October 22, 1982: Telesaver Publishes Newsletter for Area Managers; Telesaver is People; By Way of Introduction; Universal Brochures; "Telesaver... Can I Help You?"; Customer Service; Cancellations Will Be Forwarded; New Programmer... A Welcome Addition; What is the DEC Computer?; A Word About Auto Dialers; Please Remember; We Are in the News; For Your Information
- November 1982: To Keep You Informed...; Telesaver Expands Its Universal Service; A Family Business; In the News; Telesaver is People; Telesaver Comes to Hazleton!; Industry Update; Responding to the Needs of Our Customers; Welcome Aboard; New Book on the Market; Should We Sell to College Students?; Get the Message Across; A Request from Accounting; About Service Charges...
- December 1982: First 72-Path Switch Installed in Columbia, Maryland; Telesaver "Graduates" to DEC Computer; Telesaver Announces Partnership with J & J Management; Hazleton's First Month; New Business Brochure Ready for Distribution; Telecommunications in the College Classroom; A View from the Front Desk... or Musings from Julie Whitcomb; Goldman Gives Talk at Cellular Radio Conference; Non-Travel Customers Will Receive Wallet Cards; How Your Telcro II Arrives at Your Door; New Cities Added to Travel Network; Industry News; Telesaver in the News; Discover Telesaver... The New Long Distance Service that can Save...; Happy New Year!
- January 1983: Profile: A Short Circuit to Success; Dick Goldman "Stars" on Cable TV; Open House at Telesaver; Welcome Aboard; Telesaver's "Oldest" Employee; Know the Competition!; For Your Information; Bell Operating Companies Present Conference [issue courtesy of Mike Metzger]
- February 1983: Telesaver Takes a 3-Day "Holiday" for Strategic Planning; Will There Be Life After Divestiture?; A Profile on Telesaver's First Partners: The Greifs; Telesaver Survives the Blizzard of '83; Telesaver Expands Universal Service; Industry News; Telesaver Goes Through a Growth Spurt; Telesaver Sends Sharon Harmon to School
- March 1983: A Profile on Our Newest Partners: Shearman, Kane & Magnetti; Industry News; Director of National Sales/Marketing Hired; Coming Attractions...; Welcome!; Our Congratulations and Best Wishes To...; Columbia Expands Its Territory and Its Office Space
- April/May 1983: Telesaver's New Autodialer; Profile: Robert Glaser, Ph.D.; Philadelphia Has New Management; Telesaver's Truck Really Gets Around!; Shareholders Meeting Is Scheduled; Annapolis, MD, Added to Universal Network; Telesaver Leases Additional Space; Telesaver Takes Its Show on the Road; We Want You to Know...; New Promotional Materials Developed for Universal Service
- June 1983: Profile: Robert Chertkof, Executive Vice President; Happy Birthday, Columbia! Our Future According to MCI's Bill McGowan; It's a Small World!; New Manager for Network Operations (Allan Zendle); Hot Off the Press; Philadelphia Makes Great Strides; Welcome; Congratulations and Best Wishes to...; Industry News; Let Us Know
- July/August 1983: Profile: Michael T. Senate, Director of Manufacturing; Success Story: Part-Time Sales; Expansion of Universal Service to New Jersey Area; Transforming an Empty Warehouse into an Office/Manufacturing Facility; An Update on Telesaver's Universal Cities; Welcome!; Telesaver's First Company Picnic a Success; Long Distance Rates: A Comparison; Visitors to Columbia Fair "Made the Connection" with Telesaver; New Policy Facilitates Sale of Telesaver; Understanding Your Customer's Telephone System Makes the Sale Easier; Know the Competition!; For Your Information; Changes Announced for Residential Customers in Non-Universal Areas; Goldman Speaks on Partnership Approach to Resale Operation; Industry News; Will Local Telephone Service be Affordable?
- September 1983: Profile: Leonard Moskowitz, Vice President, Human Resources; Welcome!; Special Recognition to... Curtis Cavey; California Gets New Management; Bigger Means Better!; Telesaver Installs New Phone System; Where Does Your Local Company Fit into the Scheme of Things to Come?; New Contract Means New Codes for Customers; Telesaver Tests Telemarketing; Moving Up the Corporate Ladder; Mall Show Turns Out to Be a Show-Stopper; For Your Information; Update: Travel Network; Milestones; Customer Service Announces Extended Hours; Community Involvement; Everything You Always Wanted to Know About Long Distance... And More; Coming Attractions
- October 1983: "For Whom the 'Bell' Tolls..."; New Post Created to Market Telesaver's Switching Systems; Cooperation is the Key to Philly's Telemarketing Success; "The Logic and Management of Saving Money on Long Distance Calling", by Harry Newton; Welcome!; Staying on Top of Industry News; For Your Information; Telesaver Opens on Broadway; A Cause for Celebration; The Evolution of Telesaver's Corporate Image;
- November/December 1983: Telesaver Appoints Vice President, Finance (Harry Lipsitz); Area Managers to Meet in Early December; "Don't Cry Over Bell's Break-Up"; Telcro III Receives Media Attention; Taking "Account" of Telesaver's Assets; New Program for Transmission Quality Control; A "Little" Knowledge is a Dangerous Thing...; Telesaver's Traveling Road Show; Marketing the Telcro III; Columbia News; Switch Upgrades = Increased Capacity; It's Not Our Fault...; For Your Information; Happy Holidays!
- January 1984: Telesaver Hires VP, Network Services (James Peterbok); Staff Reassignments Announced by Goldman; "We're No Longer 'The Other Guy'"; "Welcome to the Bright New World of Telecommunications" by Harry Newton; Area Managers' Meeting Solves "Life-Line" Issues, Sets Goals; Bell Customer Service Deteriorates as AT&T Prepares for January 1 Split; For Your Information; Welcome!
- February/March 1984: Profile: Michael B. Metzger, Controller; Personnel Notes; Bill Link Brings 37 Years Experience to Telesaver's Network Operations; Telesaver "Retreats" for Planning Session; Telcro III Makes Its Debut at COMNET '84; "Switch Referrals -- Defined"; Telesaver "Connects" with Members via New Publication; Our Customers Write...; FCC Delays Access Charge Until 1985; Local Bell Companies Request Reentry into Long-Distance Market; For Your Information; Telesaver Has a "New Look" Beginning March 1; We Invite Your Comments...
- April 1984: Profile: Barbara Peterson, Supervisor, New Accounts; Telesaver's CEO Hits the Speaker Circuit; First Sale of Telcro III is Announced -- and this is Just the Beginning!; "Telesaver Connection" Stimulates Customers' Comments, Queries; Northern California Gets New Management (David Brown); A Warm Welcome to... Lynda Mehler; A Fond Farewell to... Francesca LoPorto-Peck; Have You Moved?; For Your Information; A Community Service...
- May 1984: Profile: Lyn Merryman, Supervisor of Credit and Collections; Telesaver's Student/Employee Receives Highest Honor; Welcome... John Potter and Jim Geisler; It Really Happened...; "Caveat Emptor!" or Let the Buyer Beware; Our Best Wishes; Telesaver Joins in Preakness Festival Week; For Your Information; New Group of Switch Technicians Trained at Owings Mills Facility; Upcoming Conferences and Trade Shows; Telesaver Announces Forget-Me-Not Service
- June/July 1984: Profile: Marshall Sapperstein Director, Sales and Marketing; "How to Spot Winning Firms;" Are All Long-Distance Companies Created Equal?; "Fastest Newstalker" Contest Resulted in High Visibility for Telesaver; Welcome!; Telcro Switch Inspired Interest at USITA Show; "How to 'Prep' for Better Sales"; System III Nears Completion -- Installation to Begin End of June; Telesaver Receives Employer of the Year Award
- August 1984: Corporate Restructuring Plan Announced at Shareholders Meeting; Telesaver Announces Rate Reductions on Interstate Calls!; Profile: Michael Yang and J. R. Perez, New Sales Managers Cover East/West Coasts; Telesaver Announces "EASEE" -- a Solution to a Market Need; Coming Attractions...; "The 65-Hour Week"; We Couldn't Have Said It Better Ourselves; Introducing...; Telesaver in the News...; Response to "Forget-Me-Not" Keeps Data Entry Busy!; Telesaver Goes to the Fair; Telesaver Announces "Sweepstakes" Contest; Let Us Know!
- September/October 1984: Telesaver Salutes Its Corporate "Olympians"; "Battle of the Corporate Stars"; Telcro III Nears Completion; Public Appearances...; Sales and Marketing Department Revamped to Meet Increasing Challenges in the Industry; "Vistacom Reports" Takes a Look at the Issues; Vistacom Update; System III Computer Installed; Rochester Customers Get "950" Service; Telesaver Moves into Hampton Roads/Tidewater Area of Virginia; Moving Around the Company...; Welcome!; Telesaver Drops All Charges for Accounting Code Feature; Heroics Worthy of Recognition...
Dénouement
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.
Epilogue
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 was General Manager (2003+) of the Pearlstone Conference & Retreat Center; he has since retired and moved to Florida. 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)
Main Projects Page
Ham Radio Projects Page
Computer Projects Page
Project Chronology Page
IC Engineering projects are on the corporate home page
All content Copyright 2025 IC Engineering, Inc. This webpage last updated: November 21, 2023