by Damien Burke
The overall nav/attack system components, showing the basic relationship between them. BAE Systems via Brooklands Museum
Development of the SLR went much more smoothly than many other aspects of the project, and EMI delivered the first test model to Weybridge in August 1961, following up just one week later with delivery of a second model to the Royal Radar Establishment (RRE) for airborne test use. The only serious delays experienced were with interfacing to the CCS and provision of suitable display tubes; unsatisfactory electrical connectors caused another minor delay. By July 1963 test models were proving so reliable that an endurance trial at RRE Malvern was terminated because the fault rate was so low that it was not felt worthwhile to continue. The RPU was another story, however, and by late 1964 there were continuing problems with the processing chemicals deteriorating in storage, and clogging the slot through which the paper passed during processing. At one point it seemed likely that the navigator would have to change the slot during longer sorties, which would have brought additional problems of sealing and accessibility. The project was cancelled before the problems were ironed out.
Central computing system
The TSR2’s CCS was based on an off-theshelf Verdan D9D unit (a pair of them in fact), produced by Autonetics Corporation, a division of North American Aviation, and manufactured under licence in the UK by Elliott Automation. ‘Verdan’ was a reduction of ‘Versatile Digital Analyzer’. It was a solid-state digital computer with two computational centres; an incremental or DA (differential analyzer) integrator section, and a whole-valve or GP (general-purpose) section. The complete memory capacity of a single unit was 1,664 words, equivalent to less than 5Kb, and was held on a rotating magnetic disc (an early forebear of modern hard disks), with an average access time of 5,000 microseconds per location. A single multiplication or division took 2,000 microseconds to be performed; but Verdan could carry out many operations simultaneously. For those more familiar with modern dual- or quad-core central processing units (CPUs) this was a hugely multi-core but very slow CPU!
Electronics and computing have advanced with bewildering speed over the last half-century, and the Verdan seems an incredibly primitive piece of equipment to modern eyes. Comparison with any current-day computer would be embarrassing. Even a 1982-vintage Sinclair Spectrum was hugely more powerful than the Verdan. However, for its time Verdan was a reliable and advanced piece of equipment, and the earlier D9A model was installed in hundreds of American aircraft and warships, primarily driving their navigation systems, and was providing accuracy and reliability unavailable by other means.
The complex calculations that tied together the inputs from the stable platform, Doppler, navigator’s fix controls and so on were all handled by the CCS, and outputs of latitude, longitude, distance to go, moving-map display and so on were all displayed in the navigator’s cockpit as a result. The CCS also handled all the computation required to fly accurately the manoeuvres involved in any kind of attack, such as the nuclear bombing loft manoeuvre. The results of these would be displayed as cues in the HUD, but were also output to the AFCS, enabling the crew to concentrate on things other than the basic flying task at the time of greatest stress and danger.
The Verdan D9D computer. The casing for the memory disk is obvious, as is the large hose providing cooling air. BAE Systems via Brooklands Museum
The computer control panel and display unit, as fitted at the bottom right of the navigator’s instrument panel. BAE Systems via Brooklands Museum
As an off-the-shelf buy, you could reasonably expect this to be one part of the TSR2 programme that did not suffer unduly from delays. However, Verdan was on the edge of its capabilities when married to the TSR2’s complex nav/attack system, and by late 1961 it was clear that even a pair of Verdan D9Ds together did not have the capacity to run the complete program required by the nav/attack system. In fact the programmers at Elliott Automation privately believed that six D9Ds would barely have coped. By April 1962, all parties involved – BAC, the RAE, the RAF and Elliotts – had agreed that the only way forward was to downgrade the specification. Each of the aircraft’s various modes would need to run a separate program, rather than having one program to cater for all modes (this was not a particular limitation as no sortie would involve, for instance, both ferrying and a nuclear-loft attack). The number of navigation checkpoints was reduced from forty to thirty, the number of bombing modes was reduced from ten to six, and approach tracks to a checkpoint and wind computations were omitted. Similar downgrades had happened already; more would follow. With further development, it was hoped, the programs the system was running could be improved and optimized and enable a more complete system to be brought back into being.
Unfortunately, while further development did indeed result in some optimization, it also showed up just how much was missing from the early system, and flight-testing of prototype units introduced real-world problems that had not been considered. Airborne trials were carried out by the A&AEE from July 1963 to February 1964 using Handley Page Hastings WD496. Programs SO1 (the first development program, intended for TSR2 development-batch use) and SO3 were tested on the standard of Verdans intended for the TSR2, along with a development model of the stable platform. Soon, SO1 was superseded by SO3, which was much more representative but only covered ferry sorties; no bombing calculations were involved. The limited ground testing that had been done on the Stage 2 rig at Weybridge was soon reflected in the airborne trials, with a variety of faults impeding progress. Of 700hr of testing, only 68hr was carried out in the air. The remaining time was made up of installation, troubleshooting, on-site repairs, investigation of engineering defects and programme testing and ground simulations. Both the Verdan units and the stable platform suffered repeated failures of one kind or another, caused by a mixture of poor workmanship, faulty components and flawed design. The accuracy shown by the CCS on this trial was unexpectedly poor, and an on-board Decca navigation system performed better. Some flights showed apparently random deviations that could not be explained. Simulated SLR fixes were not processed by the CCS until 7sec had elapsed, enough to introduce small errors at the slow speeds flown by the Hastings, but much more serious for a transonic aircraft. Turns also introduced a variety of issues, the most serious being that the CCS corrected its own integrator drifts every 25sec or so, and in turns there could be large changes in the aircraft’s velocity vector that would result in the CCS introducing rather than rectifying errors. On some occasions the CCS erroneously activated the bomb-release signal, something that would have caused great embarrassment to a TSR2 crew, particularly on the ground!
The extra computer capacity needed just to fix the problems and deal with the new items was beyond the remaining capacity available, without including the capacity needed to store navigation checkpoints, etc. There were 256 DA integrators available, and a capacity of 2,048 GP words (1,664 on each D9D, but around five-eighths of the memory disc was reserved for DA use). By September 1964, with estimated increases in program size to cater for all the outstanding problems, one of the bombing-mode programs (low-level nuclear strike) would require 308 DA integrators and 2,777 GP words. So BAC itself had a central computing system that would prevent its aircraft from ever meeting the full OR. The system’s speed was also a serious concern, with Elliotts desperately trying to improve matters so that turning points would not be overshot by several miles at supersonic speeds before the computer could catch up. Further airborne trials, this time in Comet XS235 and using programme S04, were begun in November 1964 and continued until February 1965. The results were little better than the Hastings trials. The supplied Doppler unit suffered near-constant unserviceability. Simultaneous Doppler and stable-platform failures resulted in the CCS believing the aircraft was flying at 1,125kt (1,294mph; 2081km/h), and only the unusual nature of the Comet installation allowed the operators to convince the CCS otherwise. In a TSR2 installation the navigator would have been stuck with the situation. The CCS consistently lost accur
acy in turns, the errors piling ever higher as tighter turns were carried out, and the flights that actually resulted in any valid data being collected showed that the system as it stood was up to 3,000yd (2,740m) out of position over a 100nm (115 miles; 185km) leg. Even when the aircraft was taxying on the ground the CCS could suddenly believe it was travelling along with 1,500kt (1,725mph; 2,780km/h) wind drift. Component unreliability would clearly have been a major issue for the complete system, never mind the computer capacity limitations and program errors.
Autonetics did have improved versions of Verdan under development for the Minuteman missile programme, two offering larger GP capacity in the double-unit configuration, and a new single unit with enhanced GP capacity but higher power requirements. The first two were attractive, as the existing D9D could be upgraded to match, retaining existing size, weight and power requirements. However, the DA capacity was still insufficient, so reprogramming to use more GP words would be necessary, and GP calculations were slower. The end result could be a system that would do the job – just about – with no room for future expansion, and it would still be crippled by lack of speed.
Elliotts offered an alternative system, its own MCS 920B, which was a development of the MCS 920 for the airborne environment. This provided 8,192 GP words, no DA section and thus the need to carry out a great deal of reprogramming, but was ten times faster than Verdan. The prediction was that all of the operational requirements could be met within 4,000 to 5,000 GP words. It would fit in the same amount of space as Verdan (actually slightly less, as one supporting piece of equipment could be deleted), cost less, and a trials unit would be available for airborne trials in a Comet by the end of 1964. However, delivery of the first production 920B would not be until June 1967. A miniaturized version, the 920M, would be available 18 months later and give additional weight and space saving. In fact a standard MCS 920 was not available for airborne trials in A&AEE Comet XS235 until March 1965, but a three-week trial was a complete success, the A&AEE being impressed not only by the reliability, accuracy and speed of the unit, but also by the relative ease with which it could be programmed. The 920 series of computers would all turn out to be similarly reliable (and rugged) units, with capacity for massive expansion. They would go on to be used in the Jaguar’s navigation system among others, as well as being used on satellite launcher rockets and warships.
Another competitor was GEC, which was developing, at MoA request, another 8,000 GP word computer, and this one was going to be even faster than the MCS 920B. However, it was even further away and would need to have various supporting equipment created from scratch; cost was an unknown. In the end, the only firm agreement was that a thorough study needed to be made of the alternatives, and an upgraded D9D-1 was fitted for the time being. The study was under way when the TSR2 programme was cancelled. In this area the TSR2 fell victim to nothing more than timing. In 1959 Verdan was the only realistic option, but by 1964 it was clearly obsolete, and the hesitant switch from analogue and hybrid digital-analogue computing to true digital computing was well under way. The miniaturization policy that Vickers-Armstrongs had championed in its Type 571 brochure was ahead of its time, by just a handful of years.
Automatic flight control system
The TSR2 was designed to have adequate handling, even without autostabilization, in the less-exciting portions of the flight envelope, and it was in this state that XR219 flew. The aircraft became increasingly difficult to handle at higher Mach numbers, and the deterioration in lateral stability at speeds above Mach 1.5 precluded flight at these speeds without the fin auto-stiffener being operational. Artificial feel was built into the flying control system, providing suitable feedback to the pilot so that he would not inadvertently overstress the aircraft. Beyond these basic features of the flying controls, all else was the domain of the AFCS.
Produced by Elliott Brothers Ltd, the AFCS provided autostabilization, pitch manoeuvre boost, autopilot and automatic throttle control facilities. Operation of the AFCS was via a control panel on the pilot’s starboard console, with selection of the following modes possible:
•
Automatic airfield approach using ILS signals
•
Terrain-following with altitude and track keeping down to 150ft (50m) between Mach 0.7 and 0.9 using guidance signals from FLR
•
Loft bombing and dive-toss attack manoeuvres using guidance signals from CCS
•
Three-axis autostabilization under manual control, including auto-stiffening and manoeuvre boost at low indicated speeds
•
Three-axis autostabilization under automatic control
•
Basic autopilot with individual locks for altitude (from radar altimeter), barometric height (from pressure altimeter), speed and heading, with the ability to adjust each lock while flying
•
Selection of a height or heading target to which the aircraft would then fly without overshooting
Component locations for the AFCS. BAE Systems via Brooklands Museum
Automatic Flight Control System functional layout. BAE Systems via Brooklands Museum
An Elliott Brothers AFCS advert of 1964. BAE Systems via Brooklands Museum
A mockup of the pilot’s AFCS control panel, located on the starboard console. BAE Systems via Brooklands Museum
Autostabilization provided three-axis damping of short-period oscillations that would otherwise be experienced, improving handling. The small adjustments to the flying controls made by the autostabilizer would not be reflected by control column movements, unlike larger pitch and roll demands to the flying controls, which would be fed back to the pilot via movements in the control column position. The AFCS also included pitch-manoeuvre boosting, as the combination of low aerodynamic stiffness in pitch and large pitch inertia would otherwise cause a sluggish response to pitch demands. This would be particularly problematic in subsonic dive recoveries, such as during a dive-bombing or rocket attack. Thus during manual (not autopilot) flight at subsonic speeds, the AFCS would apply a large amount of extra taileron pitch angle at the beginning of a pitch demand so that a given aircraft pitch angle would be reached more quickly than would otherwise be the case.
With so much of a sortie being able to be flown entirely automatically, and at high speed and low altitude, safety of the entire system was the number one concern. As a result the taileron control channels were duplicated and the more critical fin control channels were triplicated. A voting system was used for all channels. The AFCS control panel included four emergency cut-out switches enabling the pilot to disconnect the fin and taileron automatic controls as well as the trim follow-up and turn coordinator. More immediate means of taking back manual control were also available via the control column. A force cut-out switch would detect if the pilot grabbed the stick and made a control input, to take avoiding action for instance, and would disengage any automatic flight mode (though flight director signals would continue to be displayed on the HUD to enable the pilot to get back on track and follow the directions). Also, an autopilot disengage button was located on the left-hand side of the joystick, easily accessible by the pilot’s thumb but away from his fingers if the stick was held normally.
Terrain following – forward-looking radar (ARI.23129)
One of the most important systems on the aircraft, the FLR ended up absorbing 40 per cent of the electronic system development costs on the TSR2 project. Without it there could be no terrain following, and without that, little chance of survival in a hostile environment, because hand-flying an aircraft at high speed and low level would be a tiring job, only possible in daylight. Ferranti was the contractor chosen to develop the FLR, despite the availability of a nearly completed Autoflite system in the USA, and based it on the AI.23B. (Blue Parrot, in development for the NA.39, was similarly based on AI.23B.)
Developed to Specification No. RRE X.5647, the FLR was to provide the following facilities for the TSR2:
/>
•
Terrain following (both manual and automatic)
•
Radar ranging
•
Conventional weapon aiming, through a conventional weapon-aiming computer (a related section of the radar assembly, though largely discrete)
•
Ground mapping and fixing
•
Tanker and airfield homing (through a subsidiary oscillator and receiver interrogating a modified APN 69 beacon)
Design studies began in June 1959, and completion of the first test model was expected by September 1961, with flight trials beginning in March 1962. The basic principle behind terrain following was that the radar continuously mapped the terrain ahead of the aircraft (with the scanner ‘leaning into’ turns to compensate for curved flightpaths). If the approaching terrain impinged on a virtual ‘ski toe’ ahead of the aircraft, the TFR would command the AFCS to pull up to avoid it. If there was no terrain conflict the AFCS would be commanded to make the aircraft descend. The quality of the ride for the crew was to be determined by two things: ride height (selectable in steps of 10ft (3m) down to a minimum of 150ft (50m)), and how closely the aircraft would follow the terrain contours. The latter was determined by a rotary switch on the AFCS control panel, simply marked ‘RIDE’ and graded in five positions from 1 (soft) to 5 (rough). This would vary the length of the imaginary ‘ski’ on which the aircraft was mounted, the ‘rough’ ride being the shortest ski and resulting in the harshest pitch demands. The AFCS would not ‘trust’ the TFR inputs entirely, and would always compare its demands with the signals from the radio altimeter. If a descent was demanded and the radio altimeter indicated this would result in ground impact, the TFR’s demand would be ignored.
