The three stages of the simulation are implemented by three separate C++ programs. Data is passed on from one stage to the next through simple text files as described in section 4.1 above. The whole simulation can be run automatically by invoking a simple shell script calledrun(see appendix E.1), which in turn makes sure that all binary files are up-to-date and then sequentially invokes each stage of the simulation. The following subsections describe the internal structure of each of the three programs. The program for stage 1 (reception) is by far the most complex piece of software in this simulation, since simulating reception requires detailed knowledge about all noise sources and antenna elements as well as of all simulation parameters including operating frequency and desired duration of the simulation. The programs for stages 2 (fan beamforming) and 3 (cross-correlation and integration) are relatively straightforward since they do not require any knowledge about how their input signals have been generated. Stage 3 is basically just a simple loop, cross-multiplying and integrating all input signals.
4.2.1 Reception: model
The mainmodelprogram performs the following steps:
1. Instantiate aCCommandLineOptsobject to parse its command line arguments. CCom- mandLineOptsitself encapsulates calls to the standardpoptlibrary [JT98, Tro] for com- mand line argument handling.
2. Instantiate aModelMasterControlobject.
3. Initialise theModelMasterControlobject with the given command line arguments. Dur- ing initialisation the ModelMasterControl object will create all sources and aerials as
CHAPTER 4. FUNCTIONAL SIMULATION OF ARIES 54
specified by the command line arguments. See below for details.
4. Hand over control to therun()method of theModelMasterControlobject. See descrip- tion below.
Table 4.1 shows all available command line arguments for themodelprogram. This table has been produced by callingmodelwith the--helpargument.
Figure 4.5 is a class diagram of theModelMasterControlclass and related classes.
4.2.1.1 ModelMasterControl::init()
On call toinit(), theModelMasterControlfirst sets some basic simulation parameters such as sampling rate and operating frequency, all defined in one separate include file calledmodeldata.h. It then creates all aerials that together make up the Mills Cross. Each aerial is represented by aCAerial object. CAerialobjects have the capability of autonomously receiving signals from sources, see the description of therun()phase below.
Secondly, init()creates all the sources to be used in the simulation by calling thecreate- Sources()member function, which in turn parses the.sourcefile that contains direction and amplitude of all sources. See appendix E.2 for an example.source file and explanation of syntax. .source files do not necessarily need to be generated manually, in fact some PERL [Wala, WCS96, Hie95] scripts have been written to generate .source files for certain cases, some of which are presented in the results section below (section 4.3). After the call tocreate- Sources()returns, theModelMasterControlowns a number ofCBrainySourceobjects. Each
CBrainySourceobject represents a signal source at a given location. It has the capability of returning properly delayed signals depending on the relative position of source and receiving aerial through the use of a CDelayBufferobject. The basic (‘dumb’2) signal source itself is represented by a derivative ofCNoiseSource. For clarity, only theCNoiseSourcesuperclass is shown in figure 4.5.
CNoiseSourceobjects and derived/related classes are described in more detail in chapter 5, as they are also used in the integration time estimations presented there. See especially figure 5.1 for a class diagram ofCNoiseSourceand its derived classes.
For this discussion, it is sufficient to know that any givenCNoiseSourceobject represents 2We call this kind of source ‘dumb’ since it does not know anything about its location and can only issue a
continuous stream of samples. This is different toCBrainySourceobjects which contain aCNoiseSourcebut are also conscious of their location and of propagation delays.
Figure 4.4: ARIES system model, stage 3: Cross-correlation and integration
option description
-f, –sourcefile=filename source definition file
-s, –nrofsamples=nr. of samples Number of Samples to calculate
-n, –noisesourcetype=type Noisesource: 1 = sine, 2 = wideband random, 3 = narrowband random (CustomIIR), 4 = step
-c, –coefficients=filename filter coefficients for type 3 filters -?, –help Show this help message
–usage Display brief usage message
Table 4.1: Available command line arguments formodel
CHAPTER 4. FUNCTIONAL SIMULATION OF ARIES 56
a certain type of noise source (e.g. a random noise source with a certain bandwidth) and will advance in time by one step and return the current signal amplitude on each call togetSample().
4.2.1.2 ModelMasterControl::run()
Therun()member function is one large loop. For each iteration, it firstly triggers each source to issue one more sample by calling the respective issueSample() member function. issue- Sample()will in turn retrieve a sample from the ‘dumb’CNoiseSourceand store it inside the
CBrainySource’s internalCDelayBuffer.
ModelMasterControl will then ask each CAerial to receive the combined signals from every source by callingreceiveSignals(). receiveSignals()will callgetCorrectlyDelayedSam- ple()for each individual source.getCorrectlyDelayedSample()is able to calculate the required delay based on the position vector of the receiving aerial and the direction vector of itself (the source). It will return the sample by looking it up in itsCDelayBuffer which is essentially a continuously updated look-up table (LUT) with linear interpolation. Linear interpolation en- ables theCDelayBufferto return sample values for every moment in time, even if they are not multiples of the sampling period. In this simulation there is no need to go for higher-order inter- polation mechanisms, since the internal sampling rate used throughout is (by default) 32 times the operating frequency of ARIES, which is 16 times above the (required) Nyquist rate.
4.2.2 Fan Beamforming: beamform
The beamforming stage is implemented by a single C++ program calledbeamform. It takes one command line parameter specifying the ‘starting aerial number’n(see below). beamform
implements a sum- and delay beamformer for generating the same beams as the ones that would be produced by a 32 port Butler Matrix. It makes use of theCDelayBufferclass described above to delay samples from the aerials appropriately.
The general sequence of processing steps is as follows:
1. Get one set of samples (one line from the filesaerial<n>untilaerial<n+31>each).
2. For each beam direction: Sum the properly delayed samples and store the result in file
beam<m>wheremstands for the beam number (plus an offset ofn).
here) 64 files (beam01–beam64) representing the signals received by each of the fan beams. Again, these files can be examined directly or passed on into the next stage, cross-correlation and integration.
4.2.3 Cross-correlation and Integration: xcorr
A third C++ program has been written to implement the cross-correlation and integration stage. This program is called xcorr. It takes the signals from the fan beams and cross-correlates them to produce the pencil beams. Due to the amount of pencil beams (theoretically 1024), the resulting signals are not stored in files but integrated straight away, so that the result of this stage is a matrix of 1024 values representing integrated cross-correlation results. The basic algorithm is represented in full below, as it is at the heart of the Mills Cross working principle:
while( count < NrOfSamples ) {
// read 1 sample from each beam in the S->N arm for( i=0; i<32; i++ )
{
ifile[i+32] > > SN[i]; }
// read 1 sample from each beam in the W->E arm for( i=0; i<32; i++ )
{
ifile[i] > > WE[i]; }
// cross correlate samples for( j=0; j<32; j++ ) // S->N {
for( i=0; i<32; i++ ) // W->E {
result[j][i] += SN[j] * WE[i]; }
CHAPTER 4. FUNCTIONAL SIMULATION OF ARIES 58
} // while store_result();
The last line calls a functionstore_result(), which stores theresult[32][32] matrix in a plain text file calledresult. This file can then be read by (for example) MATLAB to generate plots of the simulation results. Some results are presented in the next section.