Radio Design Group, Inc.

View Original

Obsolescence Mitigation: How Radio Design Group Supports Legacy Equipment

SI9102 test system in action

Obsolescence mitigation is a complex process.

As crucial pieces of equipment go beyond the period of support from the original equipment manufacturer (OEM), third-party support, such as that provided here at Radio Design Group, can become quite daunting. However, this is one of the services we provide to both commercial and defense customers.

The Challenge: Supporting the DRS SI9102 Receiver

The DRS SI9102 receiver is an example of how Radio Design Group provides ongoing support for equipment that is no longer supported by the OEM. Initially developed in the late 1990s by Watkins-Johnson, this unit has been a workhorse for signals intelligence (SIGINT) systems used by many services worldwide. The receiver design was very advanced for its day and still outperforms many current units available in today's market.

Why would anybody keep using a radio that is over 30 years old? There are several reasons. First, the unit is very capable, outperforming many newer units. Second, there is no "drop-in" replacement for this unit. The interface is archaic (SCSI-2), and system-specific software commands would be needed to run the unit. These units are widely deployed, so a change in this one component of the overall system would have a ripple effect that would be very costly, both in time and money, to make a substitute work.

Capabilities Needed for Obsolescence Mitigation

Radio Design Group's obsolescence mitigation services require a range of capabilities, including:

  • Technical data package (TDP) acquisition, organization and integration

  • Engineer and technician familiarization

  • Test system hardware development

  • Test system software development

  • Obsolete component identification, component engineering, and acquisition

  • Mechanical engineering

  • Custom manufacturing of components that are no longer available

  • Circuit redesign to accommodate component substitutions

These capabilities are needed to provide comprehensive obsolescence mitigation services, as our work with the SI9102 demonstrates. Let's look at some examples:

Technical data package (TDP) acquisition, organization and integration

One of the first steps is to get the relevant technical data, which is more challenging than it seems. While extensive, the TDP for the SI9102 needed to be more comprehensive. For example, the TDP included schematics, but not all engineering revisions were included. Test procedures were covered, but there was no troubleshooting data nor explanation of the theory of operation of the many and varied complex circuits involved. Expected signals and voltages were not available, and data detailing various available configurations was limited. While these issues are not necessarily an inditement of the company supplying the material, it is frequently the reality when dealing with a design over 30 years old and where the original manufacturer has been subsumed (more than once) in the following years.

Once the TDP was received, the various files had to be organized (everything came in a .zip format) and placed appropriately in our internal file system so it could be easily found. Manuals were printed and put in binders with relevant data sheets from component vendors, with room to add engineering notes as engineers and technicians familiarized themselves with the units.

Engineer and technician familiarization

Once the data package and some of the units were in hand, the familiarization process began. Engineering studied the schematics and relevant component data sheets (remember, some of the components have not been current products for years) and worked at understanding the theory of operation. However, the SI9102 has no "local" control interface. All control functionality is provided via a computer interface. In order to operate the radio for familiarization and testing, it was necessary to build a test system to provide that functionality.

Test system hardware development

There was just one problem: The computer interface to the SI9102 is an adaptation of the SCSI-2 small computer serial interface (SCSI), which dates back to the 90s and was obsolete by this time. The OEM had supplied test program software, but it required a Windows XP machine with a SCSI-2 adapter. After some scrounging around, we put together an XP platform and, with the help of e-Bay, found an Adaptek SCSI-2 card, which turned out to be a relatively large effort. The first SCSI adapter we found was non-differential, and the SI9102 requires a differential SCSI connection. Getting a good install of Windows XP was also a bit of a challenge, as the Microsoft license server no longer supports XP installations. The IT folks got that sorted out, and we finally had a working XP system with a SCSI-2 port.

Of course, nothing goes as smoothly as you would like. We loaded up the test software, hooked up the radio, and attempted to read the condition of the various registers in the unit. The result? The software crashed. Now what?

Test system software development

To their credit, the folks at DRS did everything they could to help us get the software going. We tried several fixes, all with the same results. Something was missing in the myriad of software items preventing us from using the supplied test program, and again, the passage of more than thirty years since the original development made it hard to get the precise details that would help us solve the problem.

Knowing that we might never get the software to work, we took a two-track approach. The IT folks kept trying to get the OEM software to work, and at the same time, our software engineer who writes PC software started working on an entirely new program to duplicate the original functionality.

Good move! In just a couple of weeks, we had a new test program up and running, allowing us to move forward with familiarization, testing, and troubleshooting. Another bonus: The new software was a base on which the programmer could craft an automated testing routine, saving time and money on testing incoming and repaired units.

Completing the test software allowed the engineers and technicians to make the needed measurements and tests, helping us understand the unit's operation and develop troubleshooting and testing procedures.

SI9102 test software user interface, developed by Radio Design Group

Obsolete component identification, component engineering, and acquisition

As troubleshooting for repairs began, it became apparent that there would be obsolete parts that needed replacement. Some of these parts were easy to source. For example, the pilot light on the front panel was a small neon lamp we could source from a surplus supply house. We purchased a bulk amount, knowing this would be a standard replacement item. Some of the items were a bit harder to track down. For example, the power switch also doubled as a circuit breaker. The company that made it no longer existed, but after some sleuthing, we found that the product was still being made by the company that had absorbed the previous manufacturer. While the part was expensive, it was, at least, still available.

Other parts required a bit more effort. Substitutes had to be identified and vetted, with careful attention paid to the supply chain to ensure that counterfeit parts were weeded out and rejected.

Mechanical engineering

Chassis parts that are missing or damaged may require some mechanical engineering to recreate the damaged or missing part. In this application, the Navy fitted the receivers with a non-OEM switch guard on the front panel circuit breaker. At least one of the units that came in for repair had a damaged circuit breaker handle and no guard, so it was apparent that the guard had been added to solve a problem caused by the receiver's location exposing the breaker to occasional damage.

However, this meant that the guard was a non-standard item, so it was necessary to recreate the missing part from scratch. Once the item was drawn up, it was time to get some parts made.

Custom manufacturing of components that are no longer available

Realizing that more than one receiver was missing the guard, we opted to make a small production run of switch guards. A local machinist fabricated the parts, and we could correct all the missing guards with enough parts left over to re-fit several more units, should it be necessary. Our extensive network of machinists, metal shops, and plastic part suppliers allows us to create almost any non-standard mechanical part as needed.

In addition, if a substitute electronic component requires crafting a drop-in circuit assembly to duplicate a function, we can use our in-house prototyping system to create a custom circuit board assembly to make a "drop-in" replacement, which brings us to one of the most complex aspects of obsolescence mitigation.

Circuit redesign to accommodate component substitutions

There are situations where a damaged component cannot be found, and there is no direct substitute. In those instances, the circuit has to be modified to accomplish the same function with newer, more available components. While that has, so far, not been necessary with the SI9102 receivers, our engineering staff is more than ready to do that design work when it's required. Sometimes, the redesign simply involves changing some component values. Other times, as previously mentioned, the situation requires a complex circuit to do the job, and we have to make a "drop-in" replacement circuit board to do the job. In any case, our RF engineering expertise ensures that the substitute circuitry will perform to the original specifications so that the user does not have to bear the costs of other system modifications or retraining.

Obsolescence mitigation involves a combination of efforts.

As this example shows, keeping legacy systems functional involves a variety of interrelated efforts. There is no one "silver bullet" that can solve all of the problems encountered in keeping old yet vital equipment operational. The SI9102 program is just one example of how Radio Design Group capabilities can help keep critical defense systems online and running well, even after OEM support has evaporated. You can read about one of RDG’s recent obsolescence mitigation projects on our blog. If you have a problem with end-of-life gear and need help with obsolescence mitigation, we can help solve those issues and get your equipment back online!