By Charles Knell – I left the employment of Telemed Cardiopulmonary Systems to work at Motorola. At the time, Motorola was a leading provider of wireless communications equipment.
I started in the communications sector in a development engineering section which was creating a new two-way trunked radio. A trunked radio is one which jumps to new transmit and receive frequencies each time the user presses the push-to-talk button on the microphone. This technique greatly increases the number of users possible on a fixed number of transmit and receive frequencies. I was one of a two engineer team whose task was to rewrite the software used by the previous similar radio, which used a 6800 microprocessor. The new radio was to use a 6805 microprocessor. The assembly languages of these two microprocessors were different.
The advantages of using a 6805 were lower cost, fewer integrated circuits, and therefore less physical space used on the printed circuit card. The previous product (which we were intending to replace) was so large that it needed to be mounted in the trunk of one’s car and required an additional control head mounted under the dashboard. The control head housed the volume control, microphone, and speaker. Our new radio was small enough so that the entire radio could be mounted under the dashboard. I helped test a radio prototype in my own car.
The new product was a success, and I was selected to help the marketing team make a video which introduced the new radio to the sales teams around the world.
When the trunked radio development work ended, I moved into the VHF/UHF section of the same department. The VHF/UHF versions of the new radio used a programmable read only memory (PROM) to set the radio on the selected transmit and receive frequencies. I designed a hardware interface for the PROM so that it could be plugged into the field equipment used to program the frequencies. Also, I wrote the 6800 assembly language software for the field equipment so that it could be used to program the PROMs where the radios were sold.
When the department moved to Plano Texas, where the radios were to be manufactured, I transferred to a new switching software section of the cellular infrastructure division. Our section’s product was software for a new mobile switching center (MSC) which could handle 2500 simultaneous phone calls. Our previous MSC could handle only 250 simultaneous calls.
In the beginning, all of the new software was to be written in Z8000 macro assembly language. Eventually, we started using the C language. The hiring manager told me that understanding all of the software for an MSC was beyond the comprehension of one person. And that before the project was over, some of the software would be lost. I didn’t really believe this at the time but both things turned out to be true. I worked on this project for 23 years and there was a constant stream of people joining and leaving. By the end of the project, there were about 2200 individual programs making up the system load. On this project, I first worked on the man machine interface programs (MMIs).
The MMIs were standalone programs which accessed database tables in a way that predates the use of database management systems. They interfaced with VT100 control terminals and the database tables stored on hard disk. These programs were used to control the service states and configure processors used in the cell sites. They were also used to configure the cellular database in the MSC.
My next project was to create software for network fault management. This software was used to control the service states and configure the connections to other mobile switching centers (MSCs). Also, I wrote the MMIs needed. Network fault management made it possible to configure multiple MSCs into a network. Also, I wrote audit software which automatically restored weather related service outages of the network connections.
With time comes change, and I was assigned to write a portion of the software for cellular fault management (CFM). CFM software was used to control the service states of the processors in the cell sites. My software was used to download cell databases from the MSC to the cell sites. It could download to multiple cells simultaneously. Eventually, I took on responsibility for maintenance of all cellular fault management and guided a small team of software engineers in making fixes. I would review each problem report and specify a solution. Also, I designed a new cell audit program which reduced weather related cell outages by 20%.
My final MSC software assignment was to take on the maintenance responsibility for the switching matrix. The switching matrix was responsible for connecting the trunks from the land network to the cellular trunks, making it possible to connect a phone call. It took me months to write descriptions of all the modules of this subsystem. After completing the documentation, we could understand better how the system worked, and we succeeded in fixing a very old matrix software rollout problem. This problem made the matrix software updating process malfunction intermittently during new software rollouts. Sometimes the rollout would succeed and sometimes it would fail. Everyone involved, especially management, were particularly happy to see this problem fixed. Apparently, there was a lot of pressure from customers to receive a solution.
My final assignment in the development department was to review and approve the decommissioning procedure for our MSC. At that point, I was transferred to the requirements department. We were writing requirements for yet another new MSC. However, this time we were unsuccessful in getting our first customer.
Then, I was laid-off as part of a mass lay-off. However, Motorola was very generous with their severance package. I decided to start my own consulting business, Right Results Consulting.
Next article to read: Right Results Consulting.