The Tactical Receive Equipment (TRE) was to provide situational awareness to US military commanders. It consolidates large amounts of data (even world wide) and filters the data so that it is meaningful within a specified geographic area. It is a real time system. The US Navy was upgrading TRE (History ). The company for which I worked was subcontracted to develop the red side hardware and software.

My initial task was to work with the hardware engineer who was developing the red side printed circuit board (PCB). Although he only had a high school degree, he was one of the most capable hardware engineers that I've ever met. We exchanged the usual software/hardware trade offs. I tried to place as much functionality on the circuit board; he tried to place as much on the software. I lost many arguments based on his observation that functionality that was placed in hardware was permanent; functionality placed in software could be edited. The end result was a multilayered PCB that incorporated one MC68020 CPU and four MC68302 communication processors. Each MC68302 was able to process three communication signals, thereby allowing the TRE Red Side to be connected to 12 external devices.

One of the external devices was a KGR-96 , a receive-only digital data decryptor that provides security for the Tactical Receive Equipment. The KGR-96 decrypts Tactical Data Information Exchange System Bravo (TADIXS-B) and the TRE and TRAP Data Dissemination System (TDDS) broadcasts. I began prototyping the KGR-96 interface in the C programming language. My overriding concern was the requirement to provide a 19.2 Kbps stream of data. A software emulator (of the decrypted incoming signal) provided a test bed to determine if the reception speed could be achieved using the MC68302s. Within one month, I was able to demonstrate reception at speeds up to 54 Kbps. Unfortunately, the company president had promised the Navy that the TRE software would be written in the Ada programming language. This technically flawed decision resulted in a reception speed of 4096 bps, well below the required 19.2 Kbps speed. No matter how much I tried to convince management that the KGR-96 interface needed to be written in C (with the balance of TRE in Ada), management would not change their minds. I believe that, in large part, the project failed for this reason.

I was also responsible for two other drivers: the red-black interface that executed on the MC68020 and the serial communications interfaces that executed on the MC68302s. The heart of the red-black interface was a Light-Emitting Diode (LED) channel that allowed communications between the TRE red- and black-sides. The LED channel was specified to eliminate detectable electomagnetic signals. The serial communication driver was used on each of the MC68302s to transmit or receive tactical messages to or from other external devices.

The TRE software is reprogrammable through an External Software Load Device (ESLD). The project hardware engineer and I collaborated on the ESLD design. The final design incorporated an MC68HC11 F1 processor and had four Erasable Programmable Read Only Memory (EPROM) slots that could accommodate from 1 to 4 Mbytes of software. The ESLD drew its power from the TRE and was programmed to perform boot tasks upon connection. As part of the boot task, the amount of software that was to be transferred was determined. This was accomplished by testing from higher to lower EPROM addresses, stopping when an address test succeeded. Once the number of bytes on the EPROMs was determined, the ESLD awaited a physical button press by the operator. When the TRE detected that the ESLD was connected, it started initiating communications with the ESLD, transmitting a single character to the ESLD. When the operator pressed the button, the ESLD completed communications with the TRE. Once a communications channel between the ESLD and the TRE was established, the ESLD transferred the software using S-record format and a YModem protocol. When all software had been transferred, the ESLD gracefully shut down the transfer. The ESLD software was written in cross-assembled C and assembly language.

The Tactical Receive Equipment (TRE) project is a sad story. The need was there; the technical competence was there; but the influence of non-technical managers was also there. Observers have suggested that "The contractor selected to develop the Tactical Receive Equipment (TRE) was unable to meet specifications (whether insufficient funding or poor Space and Naval Warfare System Command (SPAWAR) oversight, or both, were the major contributing factors is still a subject of debate)." To me there is no debate, senior contractor management interference killed the project.