Back in 2014 the museum had an old ex-locking type 64 radar display console. It stood at the side of the museum as a static non-working display item. That year the museum was joined by Colin Hinson, an experienced electronics engineer who at one time worked and maintained radar equipment, including type 64 consoles, at Patrington and Staxton Wold radar sites. Colin took one look at the console and declared he would like to get it working. A working display, with nothing to drive it would only be a partial step forward, so taking a deep breath; I volunteered to provide a radar emulator to provide the necessary signals so the console could display some kind of aircraft targets. So began the development.
The original aim was to generate the necessary inputs to display a handful of representative targets, of appropriate size both in range and azimuth, moving around the display.
The console 64 is a PPI rotational scan not a raster scan display. A trace is drawn from the centre to the edge of the tube, that trace is then repeated at a slight angle difference in a clockwise direction, so that the whole tube is scanned. The angle drawn represents the direction the radar antenna is pointing. Targets are drawn by brightening up the display spot at the appropriate distance along the trace. Such scans can be produced by either a rotating coil or a pair fixed coils at 90 degrees to each other. The console 64 is one of the latter fixed coil types.
To achieve the scan on the console 64, it needs a minimum of 4 inputs. First a pair of linear ramping saw-tooth waveforms, where the maximum value varies according to sine and cosine of the display angle required. The duration of the saw-tooth equates to the time necessary for the radar transmitter pulse to return to the radar receiver from a target at maximum range. There is a zero amplitude period between the saw-tooth waveforms so that waveform repetition rate equals that of the radar Pulse Repetition Rate Frequency (PRF). Because the maximum value varies according to the sine or cosine of the angle required, the saw-tooth waveforms go through a cycle of both positive and negative going ramps. In the case of the console 64, the maximum value of the saw-tooth wave form is plus and minus 50 V.
The third input required is a pulse at the appropriate time during the saw-tooth wave form to brighten up then trace at the correct range from the centre of the tube. This pulse has a duration equal to the pulse duration out of the radar receiver. It is quite low in amplitude, being about 1.5 to 2.0 V.
The last input required is a video bright-up pulse, it is about 2.0 to 3.0 V amplitude and its positive duration exactly matches and overlaps the saw-tooth ramps. It is used within the console 64 to control and suppress fly-back artefacts on the display.
The console 64 could also take other inputs, such as range rings, IFF, Video Map, and these were considered in later modifications to the emulator.
The console 64 was used mostly on Air Defence Radar sites during from the late 50’s to the 70’s and 80’s. The long range surveillance radars on those sites during that period were T80, T84, T85, T88, TPS34 and ageing T7’s. Most sites had two or three surveillance radars, supplemented by radar height finders, typically T13, FPS-6 and HF-200. The radars on each site were driven from a common trigger generator, so that they all transmitted simultaneously to avoid damaging closely adjacent radars. A typical trigger generator operated at 250 Pulses Per Second (PPS). The radars had various pulse lengths, some of which could be varied, however a typical value, chosen for convenience for the emulator, was 10 microseconds. The surveillance radars rotated independently and were not synchronised together. Some had capabilities to change their rotation speed, or even sector scan. Again a typical rotation rate was 4 revolutions per minute and was chosen for the emulator. The various radars operated on differing frequency bands, with differing antenna sizes. Whilst it was not intended to emulate the RF side of the radars, the effects that these parameters had on radar resolution and anti-jamming were considered in later modifications of the emulator.
Owing to the familiarity that Colin Hinson had with the Staxton Wold Air defence Radar site, it was decided to design the emulator around the radars that were used at that site when the console 64 was under development and use at that site. Therefore the long range surveillance radars chosen for the emulator were T84 and T85 along with the obsolete T7 . The relevant parameters are given in the table below.
180 – 220 MHz
1215 – 1390 MHz
2.7 – 2.9 GHz & 3.0 – 3.2 GHz
Hits/beamwidth at 4 RPM
First some maths
At 4 RPM and 250 Hz PRF, there are effectively 3750 scan lines in each 360 degree sweep.
If the radar maximum range is 250 nautical miles, then the period of the saw-tooth ramp (the radar return period) is 3.075 milliseconds. The Pulse Repetition Interval (PRI) is 4 milliseconds at a PRF of 250 Hz. This gives a period at the end of each saw-tooth ramp of 925 microseconds in which to do anything that does not need to be done during the radar return inter-trace period.
If radar pulse length is 10 microseconds and the maximum range is 250 nautical miles, then there are 309 range bins in each scan line.
Initial design thoughts – mostly analogue architecture - rejected
The original aim was to generate the necessary inputs to display a handful of representative targets, of appropriate size both in range and azimuth, moving around the display.
My first thoughts for a method to drive the console 64, was to pursue an analogue approach. A linear saw-tooth ramp waveform can easily be generated by inputting a fixed voltage into an Op Amp integrator, then short-circuiting the capacitor at the end of the radar return period. The capacitor is kept short-circuited until the start of the next PRI PRF at which point the short-circuit is removed and the integrator allowed to start integrating again from zero. If the fixed voltage is replaced by a sine (or cosine) varying voltage then the final voltage of the saw-tooth ramp out of the integrator is also proportional to the sine (or cosine) of the input. This latter point is only true if the repetition period of the sine (or cosine) wave input is much less than the radar return period. In our case the repetition period of the sine (and cosine) wave equates to 4 RPM (15 seconds) whilst the saw-tooth ramp period equates to the radar return period of 3.075 milliseconds. So we easily meet that condition.
The bigger problem is generating a fully synchronised and distortion free sine and cosine wave of such a low frequency (0.06666 Hz). A common method would be to generate a sine wave, then as the cosine reference, and put it through an appropriate filter/amplifier circuit to achieve a 90 degree phase delay. The phase delay must be kept accurate at 90 degrees otherwise the trace would speed up and slow down as it rotated around the display. It could also induce distortion in the circular pattern. Achieving this with solely anagoge analogue circuit ’s, which could drift due to temperature and supply voltage variations , would have been challenging.
Each target could be generated using two comparators one on each sine and cosine saw-tooth ramp plus an And AND gate and an edge triggered monostable. Some form of hysteresis would also be necessary to give the targets the correct extent in azimuth. To make the targets move , the reference voltages to the comparator (and probably the hysteresis) would need to vary. This would be required for each target and the aim was to display a handful of targets.
It seemed to be getting far too complex to me, so I considered other options.
Next design thoughts – hybrid architecture - promising
I had been experimenting with Arduino Uno micro-controller cards for another much simple project. These had a good Integrated Development Environment, lots of support for both hardware and software. They had a good number of pins which could be programmed to be either digital Input, digital output or pulse width modulated (pseudo analogue) output. The Arduino had a clock frequency of 16 MHz, so in theory could undertake up to 160 processor operations during each radar pulse period (radar range bin) . The Arduino range of cards also featured several analogue input pins, which could prove useful (and did prove very useful later).
The idea was that an Arduino could replace the sine and cosine wave generators, and also the comparators, etc. The Arduino would use a look-up table to output two pseudo sine and cosine wave outputs, which would be used to feed external Op Amp integrators. The Arduino could also keep an internal map of targets, how they move and use internal software counters to calculate what angle to output and when to output target pulses. This looked promising for further investigation as it was a relatively simple hardware design.
Final design thoughts – could we go fully digital? – unlikely at low cost / time at present
Considering a mostly processor based system, the generation of the sine and cosine saw-tooth ramp waveforms would demand calculation of both, plus other calculations such as target range that may be required, in a 10 microsecond interval. Alternatively the sine and cosine times range values could be pre-calculated and stored in a look up array. Whilst many modern processors could easily accomplish this task, it is the conversion of the internal digital number to two analogue waveforms that becomes complex. Many processors do not make such a task easy. The most readily available processor with good support to the user for development is the Raspberry PI. When this project was first mooted, the Raspberry Pi ran at 700 MHz clock frequency and had a 26 pin GPIO. Later improved variants ran at 50% higher clock frequencies and had a 40 pin GPIO. The processing rate meant that they could undertake up to 7000 processor operations per radar pulse period (radar range bin). However the programming environment and philosophy would probably reduce this by an order of magnitude for real-time applications. The Raspberry Pi did not have any Analogue output capability, other than a simple audio output chip.
If we were to generate the sine and cosine saw-tooth ramp wave forms digitally and then output them through a DAC, then the data rate and resolution required are is as follows. Two DACS would be required, each with a output rate of at least 100 KHz to match the radar pulse length. There are 3750 scan lines in each 360 degree sweep, which equates to a minimum resolution of 11 bits. However to avoid a stepped staircase visual appearance, especially near the vertical and horizontal scan positions, this would need to be increased by 2 bits, thus the minimum resolution is 13 bits. Early on, the Raspberry Pi did not have any hardware that could provide such DACs, so a bespoke design would have to be undertaken. This was not something I wished to embark on.
I also thought that the extra effort required to learn and master a new programming environment, especially for a real-time application, would cost a lot of time. I wished to provide something quite early on, so that it would be usefully to help fault find on the console 64 and test if it was working correctly. So this architecture was not pursued. It might be promising in future to utilise the greater processing power, when I have more time and there is better hardware support available.
First feasibility Breadboard
After the above considerations, I embarked on lashing up a breadboard based upon the hybrid architecture discussed above.
The first problem encountered was choice of Arduino. The number of trace lines (hereafter referred to as strobe lines) was 3750. Whilst the Arduino programming language included sine and cosine functions, the inclusion of these in real time, once per radar PRI was considered too much. I therefore decided to compute them once when the Arduino powers up for storage in a look-up table. Only one look-up table was required for the sine values, as a simple 90 degree offset can be used to ascertain the cosine value. The look-up table would be at least 3750 bytes in size, and would occupy space in the SDRAM. This exceeded the amount of SDRAM (2k) on the UNO board which I had previously worked with.
Looking at alternative Arduino models, the Arduino MEGA 256 looked the most promising. It was similar to the UNO but had 8k of SDRAM. It had the same capabilities for output with 3 times the number of Input / Output pins. So it was initially selected as the processor model to use. It was later superseded in the development.
The next problem was the Arduino MEGA 256 outputs are pseudo analogue, in fact Pulse Width Modulated (PWM) running at a frequency of 490 Hz. The actual out resembled a square wave output zero to 5 V, with a duty factor that varied according to the ‘pseudo analogue’ voltage programmed for output. This meant that the ‘pseudo analogue’ sine and cosine wave outputs would need to be filtered to produce a smooth distortion free smooth low frequency signal. A simple single pole low pass filter was all that was necessary. However too high a cut-off frequency would leave distortion in the signal. Too low a cut-off frequency would introduce phase delay to the signals, making the precise synchronisation of the sine and cosine signals at a 90 degree phase difference more problematic. As the display scan rotation was 4 RPM, equating to a frequency of 0.0666 Hz, a cut-off frequency in the region of two decades above that frequency and similarly 2 decades below 490 Hz, seemed appropriate. The actual cut-off frequency chosen was 5 Hz.
The next problem was that the ‘pseudo analogue’ outputs from the Arduino were unipolar (zero to +5V) which the sine and cosine values needed to be bi-polar. Within the Arduino the sine and cosine values were given a DC bias of half the maximum output, which needed to be removed after output.
Both of these requirements were met using a difference amplifier, giving a little gain, and incorporating a filter, implemented using a commonly available Integrated Circuit 741 Op Amp. The output of this circuit gave a smooth sine and cosine wave, symmetrical about zero volts, with peak amplitudes approaching plus and minus 12 V.
Having now got both necessary sine and cosine waves, they could be used as inputs to simple integrators to obtain saw-tooth ramp waveforms needed. Since the sine and cosine waves were bi-polar, the peak values of the saw-tooth ramps would be also bi-polar as was required. However this gave a slight complication. To discharge the integrator and bring its output back to zero at the end of the saw-tooth ramp, the capacitor on the integrator needs to be short-circuited. A simple transistor with its base driven from an Arduino input and the emitter / collector the across the capacitor would work for solely positive going saw-tooth ramps. However a positive going output from the Arduino could not be similarly used for the negative going saw-tooth ramps. Whist some applications use relays to achieve this function, it was not possible in this instance, as the short-circuit duration would be too short (less than 0.5 milliseconds) and the repetition rate too quick (250 Hz). The solution was to use a pair of Opto-isolators back to back across the capacitor driven in parallel from an Arduino output.
These solutions produced the necessary saw-tooth ram ps with peak voltages of plus and minus 12 V. The circuits included trim pots for the DC offset and integration slope, to allow the integration slo pes to be equalised and the slope rate to be adjusted so that the peaks occurred at the maximum radar range. The integrators were inverting, but the difference amplifiers were not, thus the sine and cosine values of the saw-tooth ramps were always 180 degrees out of phase and this fact needed to be taken into account in the Arduino software.
The radar video output and radar bright-up pulses were simply provided from an Arduino digital output pin through IC Op Amps with adjustable gain for their pulse amplitude.
The saw-tooth ramps should have a peak amplitude of plus and minus 50V. This would be provided by feeding the lower voltage saw-tooth ramps into a relatively simple linear DC amplifier. However at this stage, I decided to try the see if we could achieve the basic waveforms necessary.
The circuits were assembled on a ‘Solderless Breadboard’. I decided to use plus and minus 12V for the power supplies to the 741 Op Amps was such voltages were more readily available than say plus and minus 15V.
The circuit was tested at home, with an Arduino Mega 256 attached via easily available individual jumper leads made especially for Arduino projects. The program running in the Arduino was quite simple, comprising of:
Firstly, a calculation of the sine look up table, which runs once at the start of the program.
Then three counters.
Two counters running one after the other. One to time the saw-tooth ramp period, and the other the dead-zone after the saw-tooth ramp (sweep period), both adjusted to obtain the correct duty ratio and PRF. The first counter (the sweep counter) enabled the saw-tooth ramp integrators, via a digital output pin. It also enabled the video bright-up signal, with the inverse value. This sweep counter was also tested to see if a target was present at a set value (equated to a range), which then set and reset a digital output, representing the radar video signal, for a single count period.
The running of these two counters was counted by a third counter (the strobe counter), which represented the scan strobe line. The value of this counter was used to look up the sine and cosine values, which were then output on two analogue output pins. When the counter equalled the maximum strobes lines per scan, the counter was reset to zero, equating to north on the display, and the whole process started again.
This appeared to run quite well, and allowed the component values to be confirmed or adjusted when necessary. Looking forward, I had planned that the software would output moving targets. The target position would be held in a target map, arranged by strobe line and range bin, which can easily be tested against the sweep counter and strobe counter. The movement of the targets would be calculated during the dead zone at the end of the sweep period. As the number of targets would be less than the number of strobe lines, the time taken for these calculations would vary. Thus a simple counter for the dead zone time was not feasible, as it would produce varying duty factors and thus a varying PRF. The simple solution was to include an external PRF generator, whose output was connected to a digital input pin. At the end of the sweep period, the target update process was initiated if required and then a loop entered waiting for the external PRF signal to go low, at which point the sweep counter was initiated.
To allow flexibility, I decided to use a cheap AD9850 DDS Signal Generator Module. I had experimented with these previously using an Arduino UNO to program them. It just needed four input connections from the Arduino to program its frequency, and one pin to the Arduino for the PRF signal. Since these operated at the same voltage as the Arduino MEGA, no voltage level changing was necessary. I also had the previous Arduino program code that I used, so its inclusion was relatively simple.
At this time, Colin had reached stage in the renovation of the Console 64, that some representative signals would be useful. I quickly incorporated the AD9850 DDS into the breadboard circuit and Arduino program. I also decided to skip amplifying the peak of the saw-tooth ramps from 12 V to 50V and see what would be displayed. By good fortune, Colin explained that the console 64 had the capability of displaying different ranges. This was achieved by applying varying gains to the saw-tooth ramp inputs. Thus my low voltage value saw-tooth ramps would display across the complete display tube by using a lower range setting than actually represented.
Feasibility Breadboard Tests on Console 64 Display
The initial testing was undertaken providing just the low voltage (+/- 12V) saw-tooth ramp waveforms (hereafter called X and Y scan signals) without any targets or video bright-up signal. Colin could compensate for their omission by adjusting various internal settings of the console 64. However it was not without its complications, as omission of the radar bright-up signal circumvented parts of the display tube protection circuits to stop burns on the tube face. If the x X or Y scan signals disappeared, or the console & and emulator system switched off incorrectly , then the display tube could suffer a permanent burn mark. This would be quite serious as we only had the one CRT display tube and no spares. We had one narrow escape, after which Colin introduced a modification to the console 64 to overcome this problem.
Before the first test could be started, we first had to ensure the X-scan and Y-scan signals were as expected. The design under test had incorporated two pre-set potentiometers in each integrator circuit. One to provide an offset for the zero to 5 V ‘pseudo’ analogue input from the Arduino so that it represented both plus and minus sine/cosine values and the other to adjust the slope of the following integrator. This meant performing an adjustment with both X-scan and Y-scan signals simultaneously displayed on an oscilloscope. Luckily, Colin was very adept at using the oscilloscope trigger systems to provide stable displays. The process was to first adjust the input voltage bias for each X-scan and Y-scan output so that the saw-tooth ramps were symmetrical about zero. The next step was to adjust the slope of each X-scan and Y-scan saw-tooth ramp so that it had the same peak value (nominally about plus and minus 10 volts) when it reached its peak at zero, 90, 180 or 270 degrees as appropriate.
Having undertaken preliminary adjustments we could undertake out first test. Since the X-scan and Y-scan signals had been adjusted, any off-set from the centre or oval appearance could be attributed to the adjustments needed in the scan–coil drive circuits of the Console 64 display.
The first test saw a small scan appear on the display tube when the display was set to its maximum range. As Colin had predicted, when the console was set to a lower display range, the scan could fill the display face, but showing incorrect ranges. This showed our first problem after adjustment of the scan-coil driver circuits. It appeared that the scan was not perfectly circular. Whilst the centre could be adjusted and the extent of the X (north and south) and Y (east and west) directions, the display had an appearance of having flat edges in places, rather like an old threepenny bit, but with more side. It was more apparent at the zero, 90, 180 and 270 degree positions.
At this stage we did not know whether this effect was limited to the edge of the display only, or if it affected all of the scan. To allow us to better understand what was going on, I added the circuits for the radar bright-up signals and a radar video output, together with the relevant Arduino program code to drive these circuits.
The first few Arduino programs concentrated on getting, the correct frequency and phase for the X-scan and Y-scan signals, with a radar bright-up pulse properly aligned in time. I also provided a radar video signal which comprised of a permanent pulse signals at fixed ranges, which appeared as ‘circles’ on the display tube. This suggested that the imperfections in the circularity of the display was not limited to its edges, but was something more fundamental.
The radar operators using the Console 64 normally had the benefit of range rings display, so that the range of targets could be ascertained simply by viewing. By this time, Colin had managed to trace the circuitry for this feature, and we thought it would be a good idea if it could be tested. So as a result, I modified my Arduino software, so that instead of displaying targets at arbitrary ranges, I simulated where range rings would be displayed to demonstrate their feasibility of production. The radar video output was simply plugged into the range ring input.
Range rings were displayed, but again had the same imperfections in their circularity. Our first thoughts were that the Console 64 could have a problem in the scan circuitry, but because the imperfections repeated identically each scan, this did not seem likely. The next step was to investigate if the X-scan and Y-scan waveforms had any non-linearity on their saw-tooth ramp waveforms. None was evident.
After some soul searching and scratching of heads, we came to the conclusion that the imperfection was a result of the ‘pseudo’ analogue output of the Arduino Mega only had a resolution of 8 bits (256 steps). So whilst the filters into which this ‘pseudo’ analogue output was fed had a cut-off frequency of about 5 Hz, which was low enough to remove the pulse width modulation signal of 250 Hz, it was not low enough to remove the discrete 256 steps caused by using an 8 bit analogue output. If we were to lower the frequency further, then the problem of the ensuring an exact 90 degree phase shift between the X-scan and Y-scan signals would again re-emerge.
The obvious solution was to increase the number of bits used for the analogue output from the Arduino. The Arduino MEGA and its similar models were all limited to 8 bits maximum. However there were lots of them. Whilst I could have used 2 analogue outputs for each X-scan and Y-scan, combining them on output, this was a complicated solution. By good fortune, another Arduino model had just been released called the DUE. It had two proper analogue outputs, via Digital to Analogue Converts (DACs) working at 12 bits. So switching from an Arduino MEGA to a Arduino DUE was pursued, as it would overcome this imperfections in the display circularity.
This solution also had a beneficial effect. The Arduino DUE operated at 84 MHz, and had 96 Kbytes of SDRAM, whereas the Arduino MEGA operated at 16 MHz and only had 8 Kbytes of SDRAM. So it operated some 5 times faster and had 12 times more space for program variables. The major down-side of this new processor was that it operated on 3.3 volts. This meant making some adjustments to the associated analogue circuits. The Arduino DUE was also much less robust and more sensitive to incorrect voltages on its pins. This was something we experienced, as we blew up four Arduino DUEs during our development due to various errors on our part. Luckily they were not too expensive. However, the greater SDRAM and operating speed did provide us with much more opportunities for adding enhancements to the Emulator at a later date. This is something that was exploited and is described later.
Luckily, the change over to the Arduino DUE was quite easy. The programming was the same, it was only the difference in operating voltage that needed to be accommodated. Since the sine and cosine analogue outputs used to drive the integrators now only varied from zero to 3.3 V, the input bias slope needed to be adjusted. There was sufficient variation in the pre-set potentiometers to accommodate the 3.3 V levels. However, the AD9850 DDS Signal Generator Module, which was the source for the PRF, previously used the 5V Arduino supply and interfaced to the Arduino at 5V levels. A quick check of the specification for that module revealed that it would also work at the 3.3 V levels used for the Arduino DUE. So another problem was avoided, or so we thought. We did however discover an incompatibility between the Arduino DUE and the AD9850 at a later date, but at this stage it appeared to work satisfactorily.
The first test with the Arduino DUE used exactly the same software, with one of the timing loops adjusted for correct durations of X-scan, Y-scan, radar bright-up and radar video signals. This only involved setting a single value for the number of dummy loops processed during each radar pulse bin interval. The first test also used the same ‘pseudo’ analogue outputs as available on the Arduino MEGA. This was to minimise the variations between the two systems and hence be able to ascertain reasons for any differences. We again had to undertake the initial setting up of the X-scan and Y-scan waveforms on an oscilloscope.
Once this test was satisfactory; the sine and cosine analogue outputs were moved to the two DACs present on the Arduino DUE. The X-scan and Y-scan were again checked and adjusted on the oscilloscope before applying them to the Console 64. It was with relief, to both myself and Colin, that once applied, the 12 bit analogue resolution of the Arduino DUE DACs appeared to have solved the imperfection in the display circularity.
Having established the circuit feasibility, I now set about transforming them into something more permanent. As then the emulator was still under development, it was unwise at this point to commit it to a printed circuit board. I was not experienced in using wire wrap systems, so opted for the more conventional strip board approach.
The only difficulty was providing the power supplies. I needed +12V, -12V, 5V and 3.3V plus something in the range 8 to 12 V to power the Arduino DUE. The latter was provided by a simple 9V DC mains power cube and the 5V and 3.3V was supplied from the Arduino DUE. By chance I had two small PCB mount 5V to 12V DC-DC converters, which I could mount on the strip board along with the other circuitry. This meant I only needed the one 9V DC supply.
At this stage, I also included a summing Op Amp in the radar video output circuit that allowed radar noise and jamming noise to be added. It also allowed the three signals to be separately varied in amplitude. Similarly the maximum output level of the radar bright-up pulse could also be varied.
I initially drew up the design on tracing paper so that it could be thoroughly checked prior to cutting tracks and soldering. Once designed on paper, the cutting, wiring and component soldering proceeded more smoothly, giving a reasonably neat packed board. The connections to the board were all made via individual patch pins, so that jumper leads could be used to temporarily connect it to the Arduino DUE. This allowed changes in Arduino pin allocations to be undertaken easily, and make board modifications easier.
The AD9850 DDS Signal Generator Module was also incorporated as a ‘daughterboard’ onto the strip board using IC connectors. This tidied up the wiring by eliminating the need for another set of wiring to the Arduino DUE.
I initially left space on the board for a single emitter follower circuit to drive the radar video output to be added later. I also left three Op Amps vacant to implement random noise at a later date.
With the A-Model board complete, it was connected to the Arduino DUE via jumper leads. The radar video output from the Op Amp on the A-model board was jumpered to breadboard where a simple emitter follower circuit was configured. The previously proved software was run in the Arduino DUE and the X-scan, Y-scan adjusted for the correct saw-tooth waveforms. The radar bright-up and radar video amplitudes were also adjusted for the correct levels.
The first tests of the A-model board using the radar video only and previous software was successful.
The next step was to develop the software to show something more representative.
The software was developed so that each radar sweep period was divided into 305 radar pulse bins. Each bin represented 10 microseconds, the duration of each radar pulse. An array (called the sweep array) stored a value for each bin. Another array (called the scan array) was formed that represented the whole scan. It was divided into range bins and azimuth lines. To reduce the size of the array, each azimuth line represented half the azimuth resolution of the radar with the narrowest beamwidth. Initially fixed targets were inserted into this scan array. During each radar sweep interval each radar bin was processed as follows.
The scan array for the range bin and strobe line was inspected. If it showed that a target was present, the range bin in the sweep array was given a value matching the hit per beamwidth of the radar.
If the value in the range bin of the sweep array was greater than zero then a target was present and the radar video output set to high. If the value was zero then the radar video output was set to low.
If the value in the range bin of the sweep array was greater than zero, it was decremented by one, so that after the correct number of hit per beamwidth the target disappeared.
A loop delay was inserted at the end of the processing of each range bin so that its duration was 10 microseconds, matching the pulse length of the radar.
This software proved successful, and we had plenty of processing time left in each range bin period. This was indicated by the large number of dummy loops that had to be inserted at the end of each range bin processing period.
The next step was to output radar targets at the same time as range rings. This was accomplished by simple software counter, set to zero at the start of each range sweep, and the range ring output set to high when the counter matches the number of range bins in 10 nautical miles. It is then reset to count the next 10 nautical mile interval.
We then tried this range ring output. At this time we believed the range ring input at the Console 64 was high impedance, so it was connected to the Arduino Due via a 1k resistor to limit possible feedback damage. When this was tried, the range rings did not appear as they did during the feasibility testing. After tracing the Console 64 circuitry, it became apparent that the range ring input was in fact 75 ohms, the same as the radar video. The reason it worked during the feasibility testing was that it was temporarily connected via the emitter follower circuit used for the radar video output. Having now discovered this, Colin also traced the other two Console 64 inputs, namely IFF and Video map. They were also found to be 75 ohm inputs.
As I had now found that the Arduino Due had spare processing capacity during each range bin processing interval, I asked Colin if we should also consider providing IFF and video map inputs to the Console. Understandably his answer was a resounding yes. To accommodate the fact that each input would need to drive a 75 ohm input, a small strip board was quickly produced containing four emitter follower circuits, one for each input. They were supplied from the +5V supply on the Arduino Due.
It was always our intention that the Console 64 should be retained as far as possible in its original configuration. The Console 64 needed X-scan and Y-scan signals where the peak of the saw-tooth was plus and minus 50V to operate correctly at the ranges stated on the range selector switch. At this stage, the X-scan and Y-scan signals only reached a peak output of plus and minus 10V. To achieve the required output, a linear fixed gain DC amplifier was required. There are many such DC amplifier circuits published, however most if not all use a large number of discrete components. Colin fortunately, found an unusual Integrated Circuit Op Amp (LTC6090) that could output plus and minus 75V. The necessary circuit was quite simple, being a pair of simple fixed gain inverting DC amplifiers, put together on a strip board.
After patching the new DC amplifier into the X-scan and Y-scan outputs and then into the Console 64, a series of tests were conducted. The display retained its circularity and could now be operated on its correct range settings. Unfortunately this euphoria did not last long, as during another bout of testing the 0V connection on the DC Amplifier came adrift, and the LTC6090 Op Amp suffered thermal runaway and failed. Whilst the temporary failure of the 0V was unfortunate it did demonstrate how sensitive these devices were and we decided to investigate an alternative approach rather than risk blowing up several more devices.
Colin investigated the X-scan and Y-scan input circuits within the Console 64. He discovered that they partly consisted of feedback controlled DC amplifiers, albeit using valves. He made some judicious changes to the feedback resistors, enabling the existing lower voltage X-scan and Y-scan signals to drive the Console 64 at the correct ranges as shown on the range selector switch. We therefore adopted this approach as it seemed a good compromise between retaining the Console 64 as much in its original configuration and simplifying the emulator design.
Finally, the A-model up to this point had been using patch leads between the two boards and the Arduino Due, plus flying leads to the Console 64. The setup had not been very reliable, and often would cease to function. Simply moving a lead or rebooting the Arduino Due would usually solve the malfunction. This suggested that the unreliability was probably down to these patch leads. The A-model boards and Arduino Due were therefore mounted on a single piece of wood with soldered connections made where possible and multi-pin connector used for the Arduino Due connections. The wiring was loomed and the external connections made via connector strips. This appeared to solve the intermittent failures and we achieved a more reliable setup to allow software development to proceed.
Further Software development (moving targets, different radars, clutter, IFF, jamming, Video Map)
Having now established a set of apparently reliable hardware, I could now concentrate on developing the software that drove it.
The previous version of software had fixed targets stored in a scan array. It was a relatively simple step to make these into moving targets on predefined trajectories. A relatively arbitrary limit of 400 targets was chosen. These were stored a simple array as x-position, y-position, x-velocity and y-velocity. The units used were integers, and were a sub-division of the radar range bin size so that conversion from the target array to scan array used simple right shift divide for speed.
The moving targets were updated and transferred to the scan array As follows.
At the end of each radar sweep during the inter-trace period a single target would be updated. Each target was updated in turn but only once during the 360 degree scan.
The position of each target was updated in x and y coordinates according to its x and y velocity.
The range and bearing of the target was calculated and transformed into a sweep number and range bin. These were used to set a single bit in the scan array to represent the presence of a target.
During each radar sweep, the scan array for the range bin and strobe line was inspected. If it showed that a target was present, the range bin in the sweep array was given a value matching the hits per beamwidth of the radar. The target was then erased from the scan array.
The conversion from x and y coordinates to range and bearing was made using approximations rather than accurate arctangents to save on processing time. This was acceptable as the actual track was retained x and y coordinates. It just meant that straight line tracks at an angle were displayed a slightly curved tracks on the screen. Such discrepancies are not very noticeable in practice.
This addition only gave a series of straight line tracks, all starting when switched-on or the Arduino is rebooted. In order to make the targets more representative, each target in the target array, was given a value to start displaying and a value to end displaying. The value being the number of scans undertaken from switch-on or last reboot. A scan number is incremented at the start of each scan and is used during the target update process during the inter-trace period to see if the target should be displayed. Only targets that are displayed have their x and y positions updated. This change meant that a target could have a quite complex route, stored as a series of straight line tracks, programmed into the emulator. The only limited being that the total number of tracks is limited to 400. This array is referred to as the target track array later on. To ensure that the Console 64 PPI display is never empty, a maximum scan number is also stored which normally represents the scan number of the last displayable track.
At the start of this description, I explained that there were three different radars at Staxton Wold, T84, T85 and T7. The only discernible difference on the Console 64 PPI display between these three radars during normal operation would be the width of the target paints. The varying widths were down to each radars antenna beamwidth. Thus the target paint width was simply dependent upon the hits per beamwidth for each radar.
To provide the ability to selectively any of the three radars, two switched inputs were provided to the Arduino Due. One represented the T84, whilst the other represented the T7. These were inspected during the inter-trace period at the end of each radar sweep period. If either switch was selected then the appropriate hits per beamwidth for the selected radar was entered into the sweep array when a target was present. The T7 switch took precedence over the T84 switch. If neither switch was selected then the hits per beamwidth of a T85 was used.
Some radars at the time the Console 64 was in use did not have Moving Target Indication (MTI) as it was known. This facility removed ground clutter from the radar display, but with some slight drawbacks, such as tangential fading and lower jamming resistance. The Console 64 was fitted with a anti-clutter switch that when operated simply blanked a short range of radar sweep returns. I therefore considered it useful to be able to demonstrate to visitors the use of this switch clutter to remove clutter from the display.
Whilst it would have been relatively straightforward to represent the ground clutter from an actual radar site, it would have used a significant amount of SDRAM storage. I therefore elected to produce a synthetic generic ground clutter. This was slightly more complicated but used very little SDRAM and was adequate for clutter demonstration purposes.
The ground clutter displayed on the Console 64 must be repeatable and the same on each scan. In general it also reduced as the range increased until at about 35 miles it usually disappeared as the earth curved away. In addition, ground clutter usually increases with radar frequency and beamwidth. Furthermore ground clutter usually enters the radar receiver not only via the main antenna beam, but also via the first few sidelobes. I elected to use 5 times the radars beamwidth to represent this effect. The method of producing this synthetic ground clutter was as follows.
At the start of each scan, a software pseudo random number generator was seeded with a fixed value.
At the start of each radar sweep, a pre-set threshold value is set according to the radar type selected.
At each radar range bin, the pseudo random number generator is updated.
If the pseudo random number value is less than the threshold value and below a fixed range then the relevant range bin in the sweep array is given a clutter value which equals 5 times the hits per beamwidth of the radar selected.
Hence the clutter is output using exactly the same process as targets, with the hits per beamwidth in the sweep array being reduced every sweep.
The clutter threshold is reduced by a pre-set value for the next radar range bin.
The initial pre-set threshold and the amount it is reduced each range bin is fixed for each radar type. A certain amount of trial and error was involved in establishing these values by inspecting the synthetic clutter produced on the Console 64 display for each radar type. However the decision made on the values finally adopted was guided by various published articles and research into ground clutter. It is thus considered to be a realistic representation.
The console 64 PPI can accept IFF (Identification Friend or Foe) now more commonly known as SSR (Secondary Surveillance radar) video signals. They appear on the display as ‘eyebrows’ to targets slightly greater in range by about 1 to 2 nautical miles, and slightly wider, commonly about 2.5 display width. In reality the IFF video consists of a series of pulses about 0.7 microseconds duration in a pattern giving either a ‘squawk’ code or the altitude of the aircraft. The pulse pattern is repeated whilst the aircraft is in the IFF antenna beamwidth and hence gives rise to the appearance of ‘eyebrows’ to the primary surveillance radar target.
The console 64 PPI does not have the ability to decode the IFF response, solely to display the video signal. Decoding was undertaken elsewhere. It was therefore felt no need to accurately produce a IFF pulse train, but solely represent the presence of these ‘eyebrows’ on the display. This approach was later modified when the emulator was modified to provide outputs to the Console 61 as well as the Console 64.
To add these ‘eyebrow’ IFF responses I added another entry called status for each track in the target track array. This signified whether the aircraft on that track was emitting an IFF response. It would have been possible to treat IFF responses exactly the same as the radar targets and have an IFF scan array to store each position for processing during the radar sweep period. However I considered the amount of SDRAM storage that this approach would consume was not worth the extra authenticity it would generate.
I elected to simply store if IFF responses were generated from any of the targets on each bearing, which required one hundred times less SDRAM storage. This meant that if a target that was marked in the target track array as not emitting an IFF response was on the same bearing as one that was so marked, then both would display an IFF ‘eyebrow’. This would not be immediately evident to inexperienced radar operators, and if noticed explained as a limitation of the emulator.
To implement the above approach I added a bearing status array and IFF sweep array. The process to display IFF responses was as follows.
When each target track was updated during the inter-trace period, if the track was marked as giving an IFF response, then the bearing array was set to IFF status at the location that represented the target bearing minus half a beamwidth.
During the radar sweep process if a target was present as shown by the scan array, and the bearing status array showed IFF status, then the IFF sweep array was updated. The range bin location was that of the target offset in range by a preset value. The value given to the array was equal to the hits per beamwidth for the IFF.
The IFF status in the bearing array was then reset to no IFF ready for the next target track update on that bearing.
During the radar sweep process, the IFF array processed in a similar manner to the radar sweep array.
If the value in the range bin of the IFF sweep array was greater than zero then an IFF response was present and the IFF video output set to high. If the value was zero then the IFF video output was set to low.
If the value in the range bin of the IFF sweep array was greater than zero, it was decremented by one, so that after the correct number of hits per beamwidth the IFF response disappeared.
Jamming (and Side Lobe Blanking)
The radars at Staxton Wold were Air defence radars and would have been subject to jamming if war had broken out. To test their capability, they were subjected to jamming during exercises, from jammers on board aircraft, and sometimes with jamming artificially inserted in the receiver chain.
The jamming usually materialised on the PPI display in two ways. Firstly noise-like signals which if high enough tended to cover everything and was more difficult to counter. Secondly, spirals of pulses emanating from the centre of the scan. The greater the jamming the more spirals and pulses.
The first type of jamming (noise jamming) could only be simulated by hardware in the emulator and was incorporated later. Pulse jamming could be simulated as part of the software.
The pulse jamming was simulated as follows.
A simple jamming pulse counter was formed, which was incremented at each radar bin process period.
When the jamming pulse counter was greater than a pre-set threshold value, the radar video output was set to a high, simulating a single pulse width target, if pulse jamming was selected.
The jamming pulse counter was then reset.
The pre-set threshold value differed between the three radars and on the density of jamming.
There were two jamming density cases simulated. One I call a low density scenario, the other I call a high density scenario.
The threshold value set for the low density scenario in each radars case represented the time it would take for a sweep jammer to cover the radars total possible bandwidth but with enough time in the receiver’s bandwidth to produce a single pulse width target. The low density scenario represented relatively simple jammers that operated on fixed or pre-set modes.
The threshold vale for the high density scenario was the same for all three radars. It was set at a jamming level of about 10%, in other words about one pulse every 10 range bins or one to two pulses per target hits per beamwidth.
An Arduino digital input was used to monitor if pulse jamming was selected and if so which density was selected.
Some Air defence radars are fitted with various counter measures against jamming. One particular countermeasure against pulse jamming is ‘Side Lobe Blanking’. Such radars have an Omni-directional antenna which provides duplicate signals to the radar receiver. The level of these signals is set so that they are greater than those received through the side lobes of the main rotating antenna, but less than those received through the main lobe of the rotating antenna. If a signal, such as a jamming pulse, is greater from the Omni-directional antenna than from the main rotating antenna, then it signifies it is jamming entering through the side lobes, as a result the output from receiver on the main rotating antenna is blanked. Hence jamming pulses, except those entering via the main lobe, are eliminated from the radar output on the PPI display. Hence the name ‘Side Lobe Blanking’.
I felt it would be beneficial to be able to demonstrate the differences such countermeasures would make to the PPI picture a radar operator would see. This ability was a relatively simple addition to the jamming software above.
Each target track in the target track array was marked whether it was a jammer, as not all aircraft carried or operated jammers. This was incorporated into the IFF status information for already held for each track, so that the track status now held IFF and Jamming status.
When each target track was updated during the inter-trace period, if the track was marked as a jammer, then the bearing array was set to jamming status at the location that represented the target bearing minus one and one half radar beamwidths. Side Lobe Blanking did not usually work in the main lobe and first two side lobes of the antenna (i.e. 5 antenna beamwidths in total).
At the start of the radar sweep process if the bearing status array indicated a jammer was present on that bearing, then a jamming variable was set with a value of 5 times the hits per beamwidth of the radar.
The bearing status for that bearing was then reset to no jamming.
The jamming variable would be decremented each radar sweep until it was zero.
An Arduino digital input was used to monitor if Side Lobe Blanking was selected.
If the jamming variable was above zero and Side Lobe blanking was selected, then the output of jamming pulses via the radar video output was disabled for that radar sweep.
The final input required for the Console 64 display was the Video Map video input. Up until this point, I had avoided tackling this input as it has the potential to consume a very large amount of SDRAM. To illustrate this point, the video map could have a bright-up point anywhere in the 360 degree zero to maximum range. This is over 1 million points for the radars we were emulating. If this map was stored in a similar manner to the radar target scan array, then it would consume over 140 kbytes of SDRAM. The Arduino Due only has 96 Kbytes of SDRAM, so this was not immediately feasible.
I made a decision to store the Video Map using a different method, which in the event made it easy to implement its output, unfortunately it did not make generating the data for the video map any easier. I elected to artificially limit the number of Video Map point to 6000. This was sufficient for a bright-up on each radial radar sweep and two on every other sweep. In the event it was adequate in due course to draw the coast line of the UK and some of the coast of Northern Europe on the Console 64 display.
I shall explain the method used as follows. Each radar range bin on each radar sweep bearing was allocated a number starting at zero. Thus range bin zero on the first azimuth bearing of zero had a value of zero. The next range bin on that azimuth had a value of one, the next two until the end of that sweep was reached when the value was known as ‘range bin max’. On the next azimuth bearing, the values started at ‘range bin max’ plus one, and again incremented. This continued around the scan.
I then generated a map array which contained a series of these values where a map point should be output. It was essential that the array was order in ascending values and that the lowest value was placed in array position zero.
To output the map, the process was relatively simple.
A map pointer variable was set to zero at the start of the scan.
A range bin counter was set to zero at the start of the scan.
When each range bin was processed, the range bin counter was compared to the value in the map array at the map pointer position.
If they were equal, then a map point was output by setting the relevant Arduino digital output to a high and the map pointer incremented by one.
At the end of each range bin processing the range bin counter was incremented by one.
In this manner the range bin counter always chased the value in the map array at the map pointer position.
It is obvious that the video map process was relatively quite simple, however computing the necessary entries required in the may array for complex maps, such as the UIK coast line, was not. During this initial stage of video map output, the map array was fixed with a series of radial lines of partial circles as this was easy to compute during an initialization routine. The maximum value that needed to be stored in the map array is the number of azimuth sweep lines times the maximum number of range bins per sweep. This was over one million. As the Arduino Due stored integers as a four byte value, then the map array was about 24 kbytes in size, which was acceptable.
At a later dated, this fixed internal map was adapted to facilitate setting up the various hardware settings and height finder adjustments.
A more flexible approach to Video Maps and target Scenarios using SD Cards
At this stage, the target track array and map array was populated as part of the program code. Other scenarios and maps could have also been coded for selection whilst running, but would not have been very flexible and would have been very time consuming for the benefit obtained.
It is fortunate that SD card Readers and Writers are readily available and low cost from several sources. In addition, libraries are available within the Arduino Integrated Development Environment (IDE) to use them. There is also good advice on-line how to wire them up and use them with the Arduino. I purchased a number and conducted tests to see how to use them. Provided I only wanted to utilise text files on the SD cards, then it appeared straightforward. By having a number of different SD Cards, a selection of different target track scenarios and video maps can be displayed. The variation is almost arbitrary provided the limit on target track numbers and map points is not exceeded.
The SD Card Reader/Writer only needed wiring to the SPI header and a Digital Output pin for selection. I also added another Digital Input pin to select whether the arrays should be populated from the SD Card reader, or from the internal program.
Population of the target track array and map array was relatively easy using simple read commands. Provided the text files on the SD Card were perfectly correct then no problems would be encountered. However, if the files were not perfect, then program operation could become arbitrary and unpredictable. It was therefore necessary to build into the data entry routines sufficient testing of the data on entry to test if it was valid and if not correct it, ignore it or warn about.
The criteria used for validation was pre-fixed for the various variables input. Two separate files were input, one for target tracks and another for the video map. If errors were encountered that could not be rectified, then data input for that array was abandoned and the array was populated from the program code. In addition a warning Digital output was set (used later to illuminate an LED) and the errors written to a log file on the SD card. In this way, if the output on the Console 65 PPI did not look as expected, then the log file could be inspected for the cause.
This process was initially tested using the same target scenarios and video map as used in the program. This allowed validation that the data entry was working correctly and that there were no discernible differences in the Console 64 PPI display between the two different methods of populating the arrays.
Target Track Generation
The target track data values used within the program were in units selected to minimise the arithmetic inside the program. The program used integer arithmetic and where possible binary multiplication or division for speed. This meant the values were not real-life units such as nautical miles. In addition, the track velocities required were also a function of the radar rotation rate, again to eliminate the necessity to determine a time value.
There was a fixed relationship between the internal unit of measurement of distance to real world units, that being each internal distance unit was 1/80 nautical mile. With a fixed radar rotation rate of 4 revolutions per minute, each scan was 15 seconds and each internal velocity unit represented 3 knots. The X direction was east/west with positive X being east. Similarly the Y direction was north/south with positive Y being north. The original for all distances was the radar, being zero, zero.
It is possible to generate target track scenarios manually and produce the necessary text file. To produce complex target tracks that accurately relate to one another is much more difficult. The main role of the radars that fed into the Console 64 was Air defence. I wished to produce a target track scenario and video map that was representative of that role. To help achieve that I developed an Excel Spreadsheet where target tracks could be entered into rows, using real-life units, namely nautical miles, knots, and minutes. The spreadsheet calculated the end point of each track and a separate sheet allowed tracks to be compared on a graphical chart. A third sheet converted the track into the necessary units for use on the SD card as inputs for the arrays.
I searched the Internet for information on typical intercept scenarios that would have been considered for modelling or training, but had little success. There was no information in the Museum either. If anyone has such information, its provision would be appreciated for greater realism.
The scenario I subsequently elected to produce was the intercept, by a squadron of Phantom aircraft from Coningsby, of a mass raid of Russian Bear aircraft from the north east towards the UK. Each Phantom aircraft carried 4 radar guided missiles and 4 Infrared guided missiles, thus the 12 aircraft of a squadron could in theory shoot down 96 aircraft. I produced a scenario, whereby the Russian Bear aircraft formed a box 12 wide by 8 long providing a perfect target opportunity for the Phantoms. The tracks of the Phantoms represented the type of intercept that would have been undertaken being a track south of the Bears, turning north into a tail chase. As each Bear aircraft was intercepted, its track was terminated. It was quite intricate adjusting the tracks of the Phantoms so that each row of Bear aircraft were terminated at the same time and at the correct distance away from the Phantom for the type of missile used. It was what could happen if everything went perfectly for the UK on that day.
The target tracks were also marked with the Phantoms emitting IFF for the outward and return legs of their flight, but not the intercept stages. The Bears were not marked as emitting IFF, but two of the aircraft were marked as emitting pulse jamming.
In addition to the intercept scenario above, I also added a largish number of target tracks representing civilian aircraft flying between several major airports, along the north / south airway, and east / west airway to Europe. These were all marked as emitting IFF.
Video Map Generation
Generation of the video map data was not quite as simple as the target tracking data. Firstly I needed to make a decision on what the content of the video map should be. At this stage I could only rely upon the memories of Colin. He suggested that the video maps that were in use were based upon the coast line of the UK with additions such as airways, beacons, selected airfields and sector squares. We did not have any examples, however some were found later after the first video map for the emulator was produced. It is an aim to produce a version of these real maps for the emulator at a later date.
We made a decision that the best map that we could produce at the time was a simple coastline of the UK. A search of the internet produced a small number that may have been suitable. All were in one of the generally available image formats, such as JPEG, TIFF, and GIFF.
The radar emulator used a video map format which is essentially R Theta, (range and bearing). All of the readily available maps were in raster scan format (x, y). In addition the format required for input to the radar emulator was unique to the emulator, so some form of conversation program was required. Being of senior years, my programming experience on computers revolved around BASIC and FORTRAN (for those who remember them). So not wishing to learn yet another new programing language, I turned to a simple BASIC utility called SmallBASIC, which I had been experimenting with previously. I did not need windows programming routines just simple text, file manipulation, mathematics and arrays, and it fulfilled all these needs.
The first problem I faced was to establish the data format of the image file. The easiest image file to process is called a Bit Map Picture (BMP). A lot of image manipulation programs provide the facility to save images in BMP format. A search of the Internet quickly produced a description of the BMP image format and what each byte within the file represented. It also allowed me to simply the conversion process by electing to use a black/white image as the source. I found a suitable UK coast line image that allowed me to start writing the conversion program.
The conversion process I adopted in the program was quite simple. The initial bytes in the BMP file described the horizontal and vertical number of pixels in the file and how far into the file the actual image started. I needed to input to the program, the relative positions of the corners with respect to the origin of the radar. Form this information I could calculate the range and bearing for the centre of each pixel to the radar.
I also needed to input the radar parameters for pulse length, its range in terms of pulse lengths, PRF and rotation rate. From these parameters I calculated the number of bearing strobe lines per scan. I set up an array with each row representing a radar sweep and each column representing a bearing strobe line.
It was then a simple means to test to see if each pixel was either black or white in the image, calculate its position in terms of range and bearing from the radar, and where the pixel is white (I elected to use images which were white on black), then the appropriate array position was incremented by one. When all pixels had been processed I had an array, which mirrored the emulator scan strobe lines and range bins.
To generate the necessary video map file, I simply inspected the array, starting at zero range bin, zero strobe line position, incrementing through each range bin in turn. When the array position had a value greater than zero, indicating that a white dot is present, the array position was converted into the range bin count used in the emulator. This was done by manipulation of the row and column number, and simply output to a text file as an integer.
Unfortunately life was not quite so simple. I needed to ensure that the number of range bin values output did not exceed 6000. If it did, then steps were necessary to reduce this number. This proved to be the case. I initially edited the image to remove some of the coastline detail. I then included some additional code into the conversion program to selective remove some array entries. The approach used was where two dots were adjacent in either range or bearing to remove the one which covered the lowest number of pixel from the original image.
I eventually got a sensible video map text file with less than the maximum number of entries. This was transferred to the SD Card and tested in the emulator. After a minor correction to the emulator program (I was using the wrong termination value for the read in of the file), the coastline of the UK appeared in the map video output on the console 64 PPI. It also appeared to have the correct range and origin much to everyone’s surprise, including mine. However it was not as crisp as it could be. It was obvious that the coastline was multiple pixels/range bins wide. This accounted for its large size.
Colin was very adept at image manipulation so agreed to tidy up the original image so that the coast line was only one pixel wide at any point. In the event he found a better coastline image which included the Norther Europe coast. After a tidy up from Colin, was able to run the image through my conversion program and produce the appropriate video map file, and it had less than 6000 entries. When subsequently viewed on the Console 64 PPI it produced a much better display, more representative of what was actually used in real life.
Up to this point, the boards used were mounted on a piece of wood, connected to the Console 64 via flying leads, with selections made for the various function by jumper leads. It was time to tidy up the emulator and provide a proper enclosure.
A suitable 19 inch rack mounting enclosure was found with a blank from panel. A series on BNC sockets for the many video signals, and two PL259 sockets for the X-scan and Y-scan signals were mounted on the rear panel. A multi-pin socket was also provided, for connection to the Console 64, to allow a remote selection of the radar type.
Switches for the many functions, the SD card reader/writer, and LED error indicator were mounted on the front panel. I provided a reset switch for the Arduino Due, and a USB socket on the front panel which connected to the programming socket on Arduino Due board. I provided a switch to control whether selection of radar type was local (front panel) or remote (at the Console 64) for the selection of radar type. This unfortunately did not avert later failure later due to operator error. Another switch allowed selection of map and target data to be input from the SD card or to use the fixed data from the internal program. This is in effect a test, calibration, and setup map and scenario. Finally, with a view for introducing noise jamming and its counter measure at a later date, a potentiometer and switch for those functions were also provided
It should have been a simple step to move all of the boards into the enclosure. The existing interconnection wiring was retained and new connections made to the front and rear panels. No changes were made to the software at this stage. The existing connections to the Console 64 PPI display were modified to insert the appropriate connectors for use with the new rear panel.
On switch on of the B Model all initially appeared to be working. Alas this did not last long. What do they say about tiding up things! We suffered what appeared to be intermittent failures, where the radar picture disappeared from the Console 64 PPI display. At first we thought it was due to a poor connection from one of the new connectors we had introduced. Next we considered whether our changes to the earth and zero volts connections were the source of the trouble. Adding some better grounding improved things a little, but did not solve the problem.
The remote control connections to the Console 64 for selection of the radar type were not in place at this time, and were therefore not the source of the problems either. After investigation of the many times the Console 64 failed to display, we discovered the cause was that the radar PRF had disappeared. This was traced to the AD9850 DDS Signal Generator Module no longer providing a pulse output. Rebooting the emulator usually resorted the necessary signal, but after a random time it would again disappear.
After inspecting and trying various modifications to the emulator software, all to no avail, it was suggested it could be an emc problem. The museum does operate several RAF and Amateur radios. However, the problem persisted even when these transmitters were not in operation. We decided to test if it was an emc problem with the AD9850 DDS Module by replacing it with an external signal generator. Having done this the intermittent fault disappeared. I quickly produced a plug in replacement USING A 555 Timer chip (and associated discrete components) on a small strip board with a fixed PRF of 250 Hz. I had to disable and remove the AD9850 DDS Module programming code and connections. The intermittent fault associated with the absence of the PRF generator has never reappeared after this modification.
We never did establish exactly what the emc problem was. The A model boards we mounted on wood, very close together but with the interconnections tightly wrapped with some leads double backing onto themselves. By contrast the B Model boards were mounted about 1 cm above a metal plate, further apart and in a different relative orientation. The same interconnections were used, but were spread out and not tightly wrapped. The A model may have introduced some mutual inductance in the wiring which filtered out cross talk, or the B model may have introduced some cross talk due to the metal mounting.
More Facilities (Joystick, strobe marker, Height Finder)
By the time I had solved the intermittent failure of the AD9850 DDS Module; Colin had got the Console 64 PPI display fully working and was looking to improve it. The Console 64 in the museum was an Ex RAF Locking model. It was one of the earlier types. The systems that used Console 64 PPI Displays were later subject to modification and improvement. A variant called the Phase 1A was introduced. This had a Joystick which allowed a dot to be moved on the display, overlaid onto a target, and a request made to a Height Finder for its height. When so requested the Height finder would slew onto the targets azimuth and display a short strobe line on the Console 64 display which overlaid the target, thus confirming to the Console 64 operator which target was being acted on.
The museum also had a Console 61, which was an early Display Console used with a number of Height Finders, but mostly the type 13. Colin with the assistance of Bob decided to see if they could get it operational. This proved much more difficult than the Console 64, and is the subject of a separate description.
In discussion with Colin and Bob, I thought I could extend the radar emulator to provide joystick marker and Height Finder strobe on the console 64 and display the marked targets on the Console 61 at a representative range and elevation (height).
Joystick Marker and Height Finder Strobe Mulitplexing
The Console 64 in the Museum did not have a joystick, being a Phase 1 variant, not a Phase 1A variant. Colin had two such joysticks, and with a little metal bashing and modification soon fitted one to the Console 64.
The Console 64, had separate inputs for the X-Scan and Y-Scan inter-trace periods. These were time division multiplexed onto the display drive circuits. A further input was called the Inter-trace bright-up controlled the brightness and presence of these inputs. In operation, a separate rack was used to control how this inter-trace period was used - some consoles (Type 4476) could display up to 10 inter-trace markers. A dekatron was used to mulitplex these, but the same dekatron was used to gate the Console 64 markers and so each one only showed once in 10 inter-trace periods.
We found that we could multiplex the joystick position and Height Finder Strobe onto the existing X-Scan and Y-Scan signals using some CMOS analogue switches (the effect of this is that the joystick dot moves continuously and not in jumps as it did with the dekatron - Colin). We could control, the brightness and presence of these two additional signals using the Inter-trace bright-up signal, which was the only additional output signal required. A set of such switches were introduced, one set selected whether the X-Scan and Y-Scan signals were for the main sweep period or for Inter-trace period. The other set selected whether the Inter-trace period was being used for the Joystick marker or the Height Finder Strobe.
The joystick function on the Console 64 had both a position mode and a velocity mode. In the position mode, the position of the joystick marker was directly proportional to the displacement of the joystick. But to allow precision control, its maximum movement was limited to about 10% of the total PPI display diameter. In the velocity mode, the joystick marker moved with a velocity proportional to the displacement of the stick. The selection of velocity mode was made by a press button on top of the joystick. By the use of these two modes the joystick marker could be placed with precision anywhere on the Console 64 PPI display.
In order to achieve this functionality, we needed some form of switchable integrator and summing amplifier. The joystick was connected back to the emulator so that it could supply the driving voltages for the joystick and provide the sensing voltages back that represented its displacement position. These sensing voltages were applied to simple 741 Op Amp integrators via a relay which was controlled by the joystick button. When the button was pressed the integrator were enabled, when it was released the integrators were put into hold and retained their voltage output. The output of each integrator was fed to a summing Op Amp together with the sensing voltages. The ratio of the sum was such that it was about 10% direct sensing and 90% integrated voltage, thus representing the desired marker movement.
The output from the summing Op Amps were fed to the CMOS analogue switches. When the joystick marker was required, the Arduino Due controlled the CMOS switches to route the summing Op Amp outputs to the X-Scan and Y Scan outputs and the Inter-trace bright-up set to a high for the required period. As the joystick circuits worked from plus and minus 12 v, they had the same calibration as the radar sweep signals.
The first complication with the above was getting the summation of the direct and integrated signals from the joystick correct. That means when the joystick is pushed away, the dot on the screen moves up and continues to move up when the joystick button is pressed (in velocity mode). The complication is that Op Amp integrators always invert, so the summing amplifier needs to be a difference amplifier, with different gains for the direct and integrated signals to achieve the 90% plus 10% summation. I could have simply used another Op Amp to invert the direct joystick signal, then used a simple inverting summing Op Amp, however that meant using another two additional unnecessary Op Amps.
The second complication was obtaining the correct integration time constant. There was no documentation that guided us to what that should be, our only guide was Colin’s recollections from working on the Console 64 display. He suggested it should take one to two seconds for the joystick dot to move from the centre of the display to its edge when the joystick is at its limits and in velocity mode. Using this as a guide, the appropriate capacitor and resistor values combinations were calculated. The time constant required meant that the capacitor value was or the order of several microfarads and must be non-polarised (non-electrolytic) if the resistor values were to be realistic and less than many Megohms. Luckily I found some large 4.7 microfarad polyester capacitors, albeit physically large, in the museum which were ideal. This proved very fortunate, as we later tried to replace these capacitors with physically smaller non-polarised electrolytic capacitors, only to find that they had a much higher leakage rate and caused significant drift.
The last complication, which was only sorted during breadboard testing of the circuit, was to ensure the output to the display did not drift excessively. If the Integrators did not hold their voltage and drifted, the joystick marker on the Console 64 display would drift, eventually moving off screen where they would not be seen. In this situation, as the operator would not know where the joystick marker was, they would not know what direction to move the joystick, in velocity mode, to bring it back into view. At a later date this problem was alleviated, as the operator could use the Height Finder Strobe marker to indicate the azimuth of the joystick marker. The drift in the Op Amp integrator was found to be caused by offset current into the Op Amps. Balancing their inputs by using the correct input resistances, this offset current was almost eliminated. The final circuit had a drift rate of less than 1 nautical mile in 10 minutes.
At first glance, the generation of the strobe marker appears quite complex. However, I adopted an easy solution. It may not give quite as crisp a display as used in real life, but it is acceptable for demonstration purposes. I used very similar circuits to those for the X-Scan and Y-Scan signals described earlier. However instead of continuously varying the inputs to the integrators so that the signals generated a sweep around the PPI display, they were set for the azimuth where the strobe marker needed to appear. These signals I call the X-strobe and Y-strobe signals. They were multiplexed onto the X-Scan and Y-Scan signals during the inter-trace period when the strobe marker was to be displayed. It was then a simple case of displaying a pseudo target of about 10 nautical miles in extent along that azimuth. This was achieved by setting the Inter-trace Bright-up signal to a high at the appropriate time.
The main sweep X-Scan and Y-Scan saw-tooth waveforms lasted about 3.1 milliseconds, corresponding to a radar range of 250 nautical miles. The Inter-trace period only lasted for 900 microseconds (the difference between 3.1 milliseconds and the radar PRI of 4 milliseconds due to a PRF of 250 Hz). During this Inter-trace period, the emulator had to undertake several functions:
Update the position of a single target and transform its position onto the scan array.
Test the front panel switches (radar type, clutter presence, and jamming settings) and set the value for the associated variable parameters that control the way these selectable functions are applied during the next PRI.
Update the scan position and output the analogue sine and cosine values
I had now added the need to undertake some additional functions during this inter-trace period. These being, the output of the joystick marker for a fixed period, and enough time for a complete strobe marker saw-tooth to be output. I decided to reduce the problem by alternating which of these two functions was undertaken during the Inter-trace period. As a result I estimated that the strobe marker saw-tooth output, fixed by its integration period, should be about 300 microseconds. The values of the integrator capacitor and resistor were amended accordingly.
The Arduino Due only has two true Digital to Analog Converter (DAC) outputs. These were essential and in use for the X-Scan and Y-Scan outputs as described earlier. The Arduino Due had many ‘pseudo-analogue’ outputs, using pulse width modulation. The pulse width modulation could be a problem for fast moving sweeps. However, such problems were not critical for the X-strobe and Y-strobe outputs as they were in effect static, only moving when the strobe marker / height Finder position is changed. So the Y-Strobe and Y-strobe integrators were driven from two ‘pseudo-analogue’ Arduino Due outputs. The existing filter characteristics previously used and proven with those circuits were retained to smooth these ‘pseudo-analogue’ outputs from the Arduino Due.
Joystick and strobe marker coordination
Getting the joystick to move a marker around the Console 64 PPI display was only half the problem. The intention was that the joystick would move a marker to a point on the display, the operator would make a Height Finder request (by closing a switch) and the strobe marker would move to overlay the joystick marker. The Emulator would then output target outputs at the correct time to the Console 61 height Finder display for any targets on that bearing.
In order for the Emulator to know where to output the strobe marker, it must know the position of the joystick. This was simply achieved by feeding the joystick outputs to another summing Op Amp in parallel to the feed to the Console 64. The summing Op Amp applies an offset and amplification ratio to map the plus and minus 12 V onto zero to 3.3V. Two pre-set potentiometers were included to adjust the offset and ratio, so that they could be calibrated against the rest of the system.
Because the pre-set potentiometers could in theory be miss-set, the output to the Arduino Due analogue inputs could rise above 3.3V or fall below zero volts. These analogue inputs are sensitive to under and over-voltage and are easily damaged. I thus included simple diode clamps to 3.3V and zero volts on the output of these summing Op Amps. Silicon diodes had a forwards bias voltage of 0.7V which I viewed as too great, so I used Germanium diodes which had a forwards bias voltage of 0.2V. This clamping method was not the final solution, as it gave problems, as explained later.
Colin and Bob were in the process of getting the Console 61 Height Finder display to operate with some success. As part of this process, the Console 61 needed a 3KHz sine wave input, synced to a 3KHz output from the Console 61, that varied in peak amplitude according to the Elevation of the height Finder antenna. We discussed the feasibility of the emulator to produce such an output but concluded it was too difficult. Again by luck, we discovered two Magslips in the museum that would have provided such inputs in the real system. Unfortunately they were locked solid, due to age, non-use, corrosion, etc. However after a bit of tender loving care (and some not quite so tender) they were made serviceable. A simple motor and crank and arm mechanism had one of them producing the necessary input to the Console 61. This produced a sweep rate of 10 cycles per minute, not dis-similar to that used in real life.
This allowed Colin and Bob to establish a vertical sweep Console 61 which mimicked that which would be shown for a real height Finder. It also allowed them to investigate the internal circuitry and discover that the Console 61 produced a DC voltage, which varied from -1 to -10 Volts in synchronism with the display sweep. The -1 V equated to the minimum sweep elevation, whilst the -10 V equated to the maximum elevation position. We decided that this internal signal could be used by the Emulator to establish the elevation sweep position on the Console 61 and hence produce target outputs to it at the correct elevation / height.
Since the elevation sense voltages were negative, a simple inverting amplifier with an appropriate gain could be used to generate a sensing voltage that varied from nearly zero at minimum elevation to plus 3.3 V at maximum elevation. However, there was a ripple of about 0.5 V at 250Hz superimposed on the elevation sensing voltage, so the inverting Op Amp needed to incorporate some suitable filter. The elevation sweep rate was 0.133 Hz, whilst the ripple was 250 Hz. I elected to use a filter cut-off frequency somewhere between the two at 8Hz. This was subsequently increased as explained later. I again included clamping diodes on the output of this amplifier as it was fed to an Arduino Due analogue input.
The Console 61 Height Finder display did not take radar video as its input for targets. It needed pulse modulated IF, at about 45 MHz. In addition it needed a short trigger pulse (several microseconds duration) of greater than 18 V in amplitude. To ease the requirements on the Radar Emulator, Bob undertook to produce a small box that interfaced between the Radar Emulator and the Console 61 Height Finder display. It would take in radar video pulses at 3.3 V amplitude and suitably modulate them with IF for input to the Console 61. It would also take the long, 3 milliseconds, Radar Bright-up pulse sent to the Console 64 and produce the short trigger pulse which the Console 61 demanded.
This meant that I only had to provide an additional Height Finder radar video output. This was a simple emitter follower, driven from an Arduino Due digital output, the same as provided for the video outputs to the Console 64.
The Console 61 Height Finder display would also take the same IFF video as supplied to the Console 64, thus removing the need for an additional IFF output.
Noise, Noise Jamming and Side Lobe Cancellation
As I had established that I would need to produce another board to accommodate these additional functions, I decided that I might as well tackle the problem of providing radar noise and jamming noise. I had already made provision for these inputs in the radar video output circuit on the first board.
Back in my younger days, the problem of noise was always how to get rid of it. Now my problem was how to generate it. Unfortunately, the noise had to be the right sort. It had to be white or gamma noise with a bandwidth of at least 100 KHz. A trawl of the Internet produced several suggestions, mostly based upon using a reversed bias silicon junction with lots of gain. A series of breadboard test revealed some problems in this approach. Firstly, the noise amplifier needed enough gain/bandwidth product, otherwise the output looked just like a low frequency sine wave generator. This meant having several stages of IC Op Amplifiers, with the gain of each stage adjusted so the its frequency response was above about 200 KHz. To achieve this I needed three stages of TL084 IC Op Amps. These had a gain/bandwidth product of 10 7, so I could achieve a stage gain of about 50 before I started to bandwidth limit.
This source of noise was fed via a pre-set potentiometer to the radar video summing amplifier to simulate radar noise. Another feed was taken via a potentiometer on the front panel to simulate noise jamming. The gain of noise, at the radar video summing amplifier, was greater for the noise jamming than for the radar noise. This approach meant that the radar noise and jamming noise is correlated, something that would not happen in real life. However I feel that a casual, or indeed an experienced, operator would not be able to see the difference.
Some radars can reduce the effect of noise jamming by a system called side lobe cancellation. This system uses a separate omnidirectional antenna to sample the jamming and then sum it in anti-phase with the signal from the main directional antenna. Side lobe cancellation is not effective against noise jamming that is received through the main lobe of the directional antenna. I decided to include side lobe cancellation against noise jamming to provide demonstrations of such capabilities, as I did for side-lobe blanking to remove pulse jamming.
To simulate this system the jamming noise feed from the front panel potentiometer to the radar video summing amplifier was passed via another summing amplifier. At this additional summing amplifier a signal that represented the noise suppression was subtracted. When no side lob cancellation was in use, the suppression signal is zero, and all of the jamming noise is passed through this additional summing amplifier. When the side lobe cancellation system is in use, a suppression signal is present except when the sweep position is within 3 beamwidths of the jamming target.
The easy approach would have been a simple binary high / low suppression signal, but this would not show its differing effectiveness as the noise jamming increases. I also wanted to simulate how the side lobe cancellation loses its effectiveness as the noise jamming target enters the adjacent sidelobes of main directional antenna.
To provide this varying suppression signal, I took an Arduino Due ‘pseudo-analogue’ output through an inverting filter to the input to the summing amplifier. A front panel switch controlled whether the suppression signal was simply zero or the varying signal.
Additional B Model board
The above circuits were assembled onto another strip board. I again initially used individual patch pins for the connections to allow for quick changes. This board was patched to the first board in the B model enclosure. Most of the interconnections were to the Arduino Due and the first B Model board. Colin provided the connections to the Console 64 joystick, which was terminated in a 25 pin D type on the rear panel. Additional connections for the Inter-trace bright-up and Height Finder Video were made to the rear panel. The X-Scan and Y-Scan connections from the first board to the back panel needed to be routed via the second B model board.
Software changes for these additional facilities
The first changes necessary was to provide signals to drive the multiplexers on the X-Scan and Y-Scan outputs. This was simply a case of setting two digital outputs at appropriate times during the Inter-trace period. One digital output controlled whether the X-Scan and Y-Scan outputs were from the X-Scan and Y-Scan signals generated during the radar sweep period, or alternate signals generated during the Inter-trace period. The other digital signal controlled whether these alternate signals were joystick X and Y position signals or X-Strobe and Y-Strobe marker signals.
When the Inter-trace was set to strobe output, a routine controlling the strobe output was undertaken. When the Inter-trace was set to joystick another routine was undertaken, which enabled the joystick marker, read its position, calculated the required strobe position and read the Height Finder Elevation position. These two routines were called on alternate Inter-trace periods.
When the Inter-trace was set to the joystick marker, a routine which did the following was run:
The Inter-trace Bright-up was set to high.
The analogue inputs that represent the X and Y joystick positions were read.
The x and y joystick positions were converted into a range and bearing using the same simplified method as used for transforming target positions into the scan array.
The Height Finder request input was tested, if a request was signalled, then two variables holding the desired position of the strobe marker and hence emulated Height Finder radar were set to the joystick range and bearing coordinates. If a request was not signalled then the variables holding the desired position were left unchanged.
Next the variables holding the current strobe marker position were compared to the desired position, if they were different the variables for the current strobe marker position were altered towards the desired position values.
The step size for the change was one range bin or one azimuth strobe line. This gave a azimuth slew rate equivalent to 2 revolutions per minute. Within the Emulator, the strobe marker bearing represents the bearing that the ‘Height Finder’ is pointing.
The strobe marker bearing was calculated as an azimuth strobe line, the same as used in the main radar sweep routines. This was used to look up the corresponding sine and cosine values which were output on two ‘pseudo-analogue’ outputs for input to the strobe marker integrators.
The strobe marker range was calculated as a range bin, as used in the main radar sweep routine.
The analogue input that represented the Height Finder Elevation was read.
I had generated a height Finder Elevation scan array, to use in a similar manner to the Scan array used for the Console 64. This array was arranged as a series of Height Finder vertical beamwidths high by range bins long. The analogue input for the Height Finder was converted into a number which represented the elevation angle in terms of vertical beamwidths.
The Inter-trace Bright-up was then reset to low.
When the Inter-trace was set to strobe marker output, a routine which did the following was run:
A simple strobe bin counter was used to control when the X-strobe and Y-strobe integrators were enabled. The maximum counter value was matched to the maximum range bin value used in the main radar sweep routine.
During this count the strobe marker integrators were enabled, thus producing saw-tooth ramps for the current strobe marker bearing as defined by the sine and cosine values output during the joystick routine above.
A delay routine called at each increment of the strobe bin counter to ensure the total time for the count allowed the integrators to reach their maximum values when required. In this way, each range bin for the radar sweep was matched by a strobe range bin.
The range bin counter was tested each increment. When it was within pre-set number of bins to the current strobe marker bin range, as calculated during the joystick routine, the Inter-trace Bright-up output was set to high. Thus it generated a short strobe line on the Console 64 PPI display.
The following additional routines were added to generate the Height Finder video.
As stated above, I had generated a height Finder scan array. This is arranged in a similar fashion to the main radar scan array, in that each bit represents a range bin, with each byte representing 8 range bins. At start-up of the program, I put a number of fixed targets into this array at various elevations and ranges.
The elevation angle of the Height Finder is calculated during the Inter-trace joystick routine.
During each radar sweep, the Height Finder scan array for the range bin and elevation angle was inspected. If it showed that a target was present, the Height Finder video digital output was set to a high, otherwise it is set to a low.
At this stage no targets were erased from the Height Finder scan array.
The process was kept simple at this stage to ensure that we could test that the Console 61 displayed targets correctly.
The following additional routines were added to simulate side lobe cancellation against noise jammers.
Each target track in the target track array was marked whether it was a noise jammer, as not all aircraft carried or operated jammers. This was incorporated into the IFF status and pulse jammer information for already held for each track, so that the track status now held IFF, pulse jamming and noise jamming status.
When each target track was updated during the inter-trace period, if the track was marked as a noise jammer, then the bearing array was set to noise jamming status at the location that represented the target bearing minus three radar beamwidths. Side Lobe Cancellation did not usually work in the main lobe and first two side lobes of the antenna (i.e. 5 antenna beamwidths in total.
A side lobe cancellation variable (SLC-SUP) is used to store the amount of noise jamming suppression to be applied at each radar sweep. This variable is output to ‘pseudo-analogue’ output at the start of each radar sweep. If side lobe cancellation is off, then this variable is always set to zero. If side lobe cancellation is on, then this variable is set to 4096 (12 bits maximum value) except within 3 beamwidths of a noise jamming aircraft. The variable is then changed as follows.
At the start of the radar sweep process if the bearing status array indicates a noise jammer was present on that bearing, then a variable (SLC-VAR) containing how much the noise jamming suppression changes per sweep is set according to the radar type. The presence of the noise jamming aircraft is then cleared from the bearing status array.
At start of each radar sweep, the value of noise jamming suppression variable (SLC-SUP) is reduced by the above variable (SLC-VAR).
When the noise jamming suppression variable (SLC-SUP) reaches zero, it is then increased each radar sweep by the suppression change variable (SLC-VAR) until it reaches a value of 4096. At this point the noise suppression change variable (SLC-VAR) is set to zero.
This means that noise jamming suppression is again applied in full until the radar sweep position is within 3 beamwidths of the next noise jamming aircraft or the same aircraft the following scan.
Testing of additional facilities
With the additional B model board wired up and the new software installed, the emulator was tested with the Console 64 PPI display and Console 61 Height Finder display.
The first problem observed was fly-back traces showing between the origin of the radar PPI scan and the joystick position and strobe marker positions. This was traced to insufficient time allowed between switching X-Scan and Y-Scan outputs from the main scan to the strobe marker and joystick outputs. Inserting a delay before these functions were outputs cleared this problem.
Having eliminated the fly-back traces, it was not possible to see clearly if the strobe marker moved to the joystick position when requested. In general it was found to work, with the strobe marker being close but not always coincident with the joystick position. The strobe marker was also not as crisp and clearly displayed as Colin remembered. Aligning the strobe marker to the joystick position was improved by adjustment to the pre-set potentiometers that were part of the additional circuits and were provided for this reason. However some misalignment remained. This was further investigated later.
The strobe marker moved in bearing and range in a smooth linear manner but stopped abruptly when reaching its requested position. In real life, the strobe marker represented the height Finder pointing angle and its rate of movement increased and decreased according to its distance away from the requested position. This was again something I decided to explore and improve later.
Another oddity was that the strobe marker followed the joystick smoothly when moved around the display except when it was moved anticlockwise through the zero azimuth. In these cases it jumped from the zero azimuth to the requested joystick azimuth.
The synthetic radar noise introduced with these additions did not look as realistic as Colin remembered. The radar noise appeared to be more ‘spikey’ and less ‘grass-like’ than remembered. The noise generated and after the radar video summing amplifier looked fairly realistic, which suggested the change in noise characteristics was after that point. The console 64 expected target pulses of about 1.5 V, with a ‘grass-like’ noise level of about 0.5 V. This was achievable at the output of the radar video summing amplifier. What we had overlooked was that the emitter follower circuit used to drive the 75 Ohm console 64 input acted as a threshold device with a value of about 0.7 V, thus only the peak spikes were passed giving the noise a ‘spikey’ appearance. This was solved by applying a DC offset to the radar video summing amplifier to overcome the emitter follower threshold.
With the front panel potentiometer turned to maximum, the noise jamming was not sufficiently intense to simulate severe noise jamming. However the simulated side lobe cancellation did provide a reasonable simulation of its effects on noise jamming. So this was another problem to explore later.
After some adjustments to Bobs interface box, static targets appeared on the Console 61 Height Finder display. I had programmed targets at zero, maximum elevation and somewhere in between. The targets at zero and maximum elevation appeared to be missing whilst those in between showed but with an anomaly. The targets ‘painted’ on both the upward and downward sweeps, each target was offset in elevation in the two sweep positions. The target was slightly lower, by about half a beamwidth, on the downward sweep from its position on the upwards sweep. However, getting targets showing was a major step forward, as it proved the interfaces worked and the major part of the software addition for this function worked. The offset problem was solved at a later date.
The additional B Model board was connected to the other boards and the Arduino Due using patch leads. At some point during testing, the system failed to work as anticipated. Investigations revealed one of the DC to DC converters supplying the +12V for the boards had failed. I was not able to ascertain whether this was due to an overload or a wiring fault. The two DC to DC providing plus and minus 12 V were replaced by two mains powered 12V switched mode power supplies, which I hoped would be more resilient. This later proved an optimistic assumption.
By this stage, the B model consisted of three boards, plus the Arduino Due with many interconnections between then and to the front and rear panel. It could have been described as a right ‘rats nest’. We had by now, got most of the circuits working and proven. Colin was very adept at producing prototype circuits using wire wrap techniques. He offered to reproduce the circuits on the three B model boards onto a single board fitted with an edge connector. This was gladly taken up, as it would make the installation much neater and simply the wiring.
It took me about 3 months in total to plan the layout and produce the three B Model boards using strip board. It took Colin about two weeks to produce the same circuits on a single wire wrap board. He used standard dual in-line Integrated Circuit holders for all of the Integrated Circuits and to hold the discrete components. This latter technique allowed quick and easy changes of component values, which helped during later modifications to solve the various observations made previously. This proved the benefit of wire wrap techniques, provided you had the right tools and enough practice.
To be continued
Resolving outstanding problems
Interactive and representative Height Finder targets
More representative IFF pulse chain
Page Copyright © Paul Edwards 2018
Page last updated by Colin Hinson 26th March 2018