Ron Ayres, aerodynamicist on the Bloodhound SSC project, was also the senior aerodynamicist for the Bloodhound guided missile, a key part of our Cold War defence system. Ron says, “In 1956 I joined the Guided Weapons division of the Bristol Aeroplane Company (before it became part of the British Aircraft Corporation) as an aerodynamicist. During my 11 years at that company I held several positions including, for five years, that of Chief Aerodynamicist. One of the principal projects that I worked on was the Bloodhound surface-to-air anti-aircraft missile. Thus you can see that the name of the Bloodhound SSC record car has a provenance!”. [Source: http://www.bloodhoundssc.com/project/team/ron-ayers]. We at the Bloodhound Missile Preservation Group applaud Ron for his missile work and of course for the SSC. Find out more about us at www.BMPG.org.uk
Month: October 2017
Work Day 21st October 2017
Now that the simulator start-up fault has been resolved it was time to put all resources back in to continuing the restoration of the LCP and the T86 cabins.
LCP
One outstanding task on the LCP cabin was to complete the painting of the cabin’s steel base band. The photo below shows the front elevation of the LCP with its ‘shiny’ black base band, a second photo showing restored roof catches. Note, the awning is a temporary arrangement acting as a dust cover and the roof catches have yet to be screwed down.
And here are just two of the restored roof catches. Both images illustrate the quality of the restoration being undertaken.
T86 Radar
Water Ingress
The cabin roof section around the pedestal is fabricated from mild steel as opposed to the alloy construction of the rest of the cabin. As a result of the many years in open storage the sheet steel on the roof has become badly corroded and in one place seen below has corroded right through allowing water to enter the cabin roof section below the pedestal.
Neil investigated the hole in the roof section found it contained a substantial amount of water. The water has now been vacuumed out and an endoscope used to examine the roof void which revealed the void to be sound but obviously affected by years of water immersion. It was fortunate that water had not entered the cabin itself from the affected roof void. Repairing the pedestal roof section will be a priority task.
Cabin Floor
The original plywood that covered the cabin floor was removed some time ago as it was water saturated and completely rotten. Work has now started on replacing the flooring before vinyl can be laid. An accompanying photo shows Dave cutting out a large floor section and further images will be available as the new cabin floor takes shape.
Air Conditioners
There is no plan to restore the original air conditioners in the cabin but they have been eased forward in their mounting to check the external seals. An important task as one of the main objectives is to ensure the T86 cabin is water tight in case it has to spend time in the open at some time in the future. Two accompanying photos show the air conditioners pulled forward (with thanks to the guys on our Facebook page for their assistance with the process of extracting the ACUs )
There is certainly evidence of water ingress in the drawer void.
The seals were found to be in good condition so the assumption is that water entered the cabin through the actual air conditioners due to the external covers being left open during the radar’s time in open storage.
So we are moving ahead again but any help or donations on offer is much appreciated. Anyone fancy sponsoring some materials such as new flooring vinyl for the T86 and LCP?
Work Day 7th October 2017
The focus has been on getting the LCP fully serviceable again so no other topics to report on until now. I am delighted to be able to say that serviceability has indeed been achieved; the investigation has revealed that we had, at least, two faults:
Fault 1
The ‘Mode Change Not Allowed’ fault was due to a faulty GX processor for whatever reason it was not reading PeriBus replies from just the Digital Input box. We shall have to research this to help identify what could be wrong with the GX.
Fault 2
The ME186 PeriBus converter was preventing the initialising of the software which was preventing the Bloodhound banner from displaying. This fault occurred last Saturday and was additional to Fault 1.
Resolution of the problems has been delayed, in part, due to the unknown condition of spares, especially GX processors. Serviceable GX and ME186 are now installed with known good spare GX in the LCP. Back in the workshop we tested it by installing and running the simulator.
We established early on that no inputs were being read from the Digital Input box and Stuart’s software analysis showed us what should happen and the messages that should be displayed depending on the Mode and Roll switches on the console, but whatever we did it was always the same message that was stopping the simulator booting – ‘Missiles not at Reload’ indicating the A and B Reload/Available switches where in the wrong ‘Available’ position which they were not. All other aspects and indications of the boot sequence were correct, displays, flashing lamps etc. but nothing happened when pressing the Simulator button.
Initial indications pointed to a problem with the Digital Input box or a switch, an obvious place to start. Could it be a faulty input card ‘locking’ data bits, could it be a faulty Serial to Parallel converter? Fortunately we have a spare Digital input box so I built a test rig consisting of my PeriBus simulator, a Digital Input box and switchable inputs to Slot 14, all cards were rotated through Slot 14 for testing. Slot 14 was used as it was the only card position that used a single input socket (OA8) and the slot also used the lower voltage (3V) bias. I had an original OA8 wired socket, carefully salvaged by Mike with all other wiring and connectors from a derelict LCP at Luffenham. It was simply a case of adapting it to connect to a +5V supply to simulate switched inputs. With this rig I could test all input cards, Termination Buffers and Serial to Parallel Converters. Several faults were found including a Serial to Parallel converter with a U/S 74S04 [amazing how many of this gate device has been a problem! – Ed] setting two data bits permanently, an input card with a U/S LM337 giving a bias of 11 v instead of 6v and an open circuit leg on a plug in DIL component (Ferranti PAL) due to oxidisation. All good stuff and an expectation that the fault would be cleared, but it wasn’t.
It was appreciated from the beginning that there could be a PeriBus problem and other fault finding measures including swapping out the ME186 PeriBus converter on the A700, as well as all other cards except the GX. The reason being that the spare GX in the LCP was definitely U/S. I originally considered the GX to be the likely problem as it was handling all other routines for starting the simulator software. Surely if there was a problem with the PeriBus it would affect everything that is connected to it. The Serial PeriBus cable and termination were also replaced.
On Saturday Sept 30th, Pete M and I tested the Digital input box in-situ with the PeriBus test set and all looked to be OK and working normally. Attention then reverted back to the A700 and the GX as it was the only item not swapped out. Removing and reinserting the GX caused another problem (fault), the boot message on the FT81 only displayed the three initial lines then everything stopped, the boot sequence was not completing to the stage it was with the ‘Missiles not at Reload’ message. Priority was now to get a serviceable (spare) GX. I am able to test GX processors to a point where the software can be booted but it does not proceed past the first line of the boot message, normal for a standalone A700 which is what I have at back in the workshop [used to be called home for Pete H! – Ed]. On Saturday I arrived at the LCP with two spare GX’s. Both GX’s then gave the same fault of the first three lines of the boot message on the FT81 – both GX’s could not have the same fault. Swapping cards revealed it was the ME186, PeriBus Converter, causing the three line boot fault. We now had two faults, the ME186 obviously going U/S on Sept 30th.
Once the ME186 was exchanged and a working ‘spare’ GX was fitted in the A700 the simulator booted correctly and ran as expected, fault fixed. I then spent an hour breaking the rule of, ‘if it’s working don’t touch it’, swapping back in the original faulty GX and ME186 to prove the fault conditions which confirmed the original GX was the cause of the permanent ‘Missiles not at Reload’ status message and the ME186 was the cause of the halted boot after three lines, this elimination task was needed to prove that we had two separate faults and this it wasn’t the ME186 causing both all along.
Moral of this saga, always ensure we maintain a set of known good spares in the LCP. What follows on from this fault is our ability to repair faulty cards. I have started on the Digital Input box and look to extend this testing capability to all I/O boxes and their cards. The challenge is to test and repair A700 cards, i.e. no extender cards exist for a start; then there is the fact that we do not have any test specifications.
As Dave has already suggested, a fault log is required and steps are in hand to set one up to be kept in the LCP.
To help understand which processor handles which task our software guru has been studying the Argus 700 source code [Coral 66 – Ed] which is from another military customer’s archives but close enough to the RAF’s and came up with this list of definitions in the BHMACRO file which shows which processors in which tasks are run. SYSSUP, which does all the MODE and ROLE button input reading, would seem to be running in GL2:
‘COMMENT’
+ Task numbers for BH2 programs. Bracket comments
+ show the processors that run each of the programs.
;
‘DEFINE’ ZM BHINIT TASKNUM “£37”; (GX)
‘DEFINE’ ZM FIREGL TASKNUM “£40”; (GL1)
‘DEFINE’ ZM TIRDOPP TASKNUM “£41”; (GL1)
‘C’ Task number £42 is spare ;
‘DEFINE’ ZM BHIDLE TASKNUM “£43”; (GX)
‘DEFINE’ ZM CFIRING TASKNUM “£44”; (GL2)
‘DEFINE’ ZM LCPFORE TASKNUM “£45”; (GX)
‘DEFINE’ ZM LCPBACK TASKNUM “£46”; (GX)
‘DEFINE’ ZM SYSSUP TASKNUM “£47”; (GL2)
‘DEFINE’ ZM FIREGX TASKNUM “£50”; (GX)
‘DEFINE’ ZM FIRESM TASKNUM “£51”; (GX)
‘DEFINE’ ZM ECIO TASKNUM “£52”; (GX)
‘DEFINE’ ZM TIRSM87 TASKNUM “£53”; (GX)
‘DEFINE’ ZM ADCLINK TASKNUM “£54”; (GL2)
‘DEFINE’ ZM MISEXGM TASKNUM “£55”; (GX)
‘DEFINE’ ZM DEBRIEF TASKNUM “£56”; (GL1)
‘DEFINE’ ZM DISPLAY TASKNUM “£57”; (GL2)
‘C’ Task numbers £60 to £63 are spare ;
‘DEFINE’ ZM DOPPLER TASKNUM “£64”; (GL1)
‘DEFINE’ ZM FDCP TASKNUM “£65”; (GL2)
‘DEFINE’ ZM LIBTASK TASKNUM “£66”; (GX)
‘DEFINE’ ZM SYSTATE TASKNUM “£67”; (GX)
This indicates that not all tasks are fixed to a processor but this begs the question, how are non-fixed tasks managed; assigned dynamically or shared perhaps?
We initially assumed (mistakenly) that the GX was OK because the system correctly read the console keyboards. The keyboards are read by the BHTEST.BH2 task, which it seems is not fixed to a processor. Note also that CHARGE displays were not affected because FDCP is fixed to GL2.
If the above makes sense to you it might mean you are an expert with Coral66; please make yourself known if you are.
Big hooray; we ran the simulator again today for a visitor and it remains ‘S’
BMPG 