Back in 2015 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.
Go to ??????????????????????
Target track scenario generation
Noise and jamming
Side lobe cancellation
Page Copyright © Paul Edwards 2018
Page last updated by Colin Hinson 24th February 2018