NCSARSIM is a program to control the operation of the method-of-moments
program NEC to simulate SAR imaging of a target that is moving in some
fashion.  (It can handle the case of no motion too.)  Basically, after
inputting various information, NCSARSIM creates a NEC input file
(SARRUN.NEC) that contains multiple geometrical structure definitions.
Each structure corresponds to a differnt SAR azimuth angle and represents
a shifted or rotated version of the previous structure.  For this to work,
before running NCSARSIM, you need to create a special NEC input file.  It
will be called here the "master NEC input file."  This master file should
describe your basic structure in its static state.  Rather than assume
that all wire segments (whether explicit or implied, via GA cards, for
example) are to be involved in the SAR target motion, this program uses
NEC's GM card capability of only moving part of the overall structure.
For this to work, there needs to be a slight alteration to the NEC input
file from what would work if you were just running NEC directly on the
static NEC input file.  First, the geometry specification cards corres-
ponding to the wire segments that are to move in some fashion must all
be grouped together.  (All such segments will move in exactly the same
way.  No allowance is made for different segments to move in different
fashions.)  When you create this input file, note the tag number of the
first segment in this group.  At the end of this group of segments,
there needs to be a "GM line" containing just the leading "GM" string,
nothing else.  If the last line in that group is already a GM line that
you're using as part of your basic structure definition, the blank GM
line just mentioned goes AFTER your GM line.  If you don't include this
blank GM line, all wire segments specified in the geometry section will
participate in the SAR target motion.  This NEC input file need not
actually contain any lines after the GE card, and it doesn't really need
the GE card either.  (But if the GE card isn't there, make sure that
there are in fact no NEC lines after where it would otherwise be--for
whatever reason you would have a NEC input file created that way.)
Perhaps obviously, the blank GM card above can't be the first card in
the geometry section.  That just wouldn't make any more sense than a
regular GM card there.)  The program gets the name of this input file
(the "master NEC input file") from the command-line.  If the command-
line is blank, it prompts you for the name of the file.  Further, you
don't even need to have any CM cards or a CE card in the file.  (However,
you DO need a CE card if you have CM cards.  No check is made for that
anomaly.)

When NCSARSIM is finished creating the actual input file to be used by
NEC, it automatically runs NEC and then NCSARGEN, which, again after
inputting more information from you, reads the field data from the output
file created by NEC's PL card and generates a SAR image.  If you make only
a static image, the image data is output to SAR.BIN.  NCSARGEN also has
the option of making dynamic images.  If you choose that option, it
outputs the individual images to SAR.1, SAR.2, SAR.3, etc.  (SAR.BIN
stores complex image data.  The dynamic image file SAR.1, SAR.2, ... store
pixelized image data.  NCSARGEN also, in the dynamic imaging case,
calculates the cross range and down range centroids of the individual
images and outputs them to the files CENTROID.CRS and CENTROID.RNG,
respectively.

NCSARSIM and its auxiliary programs run from the DOS command-line.  They
should for the most part work with Windows (but see a later discussion).
You generally can use whatever implementation of NEC that you wish, but
there are a couple of caveats.  First, your version of NEC must be able
to be run from a DOS window (or DOS itself).  Second, it must be a version
where, in normal operation, you run it and then it prompts you for the
name of an input file and then an output file--NOT where you use "<" and
">" redirection symbols to specify the file names on the command-line.
(If that's a major problem for you, let me know.  I can rework things.)
The third point relates to the output file generated when you use NEC's
PL card.  This file is important to NCSARGEN and so NCSARSIM includes the
PL line in each of the structure specifications in the NEC input file it
creates.  Your version of NEC must be such that the output from a PL card
in a multiple-structure NEC file is appended to data written from the last
PL card encountered in that file.  If it overwrites data already present,
your version of NEC is incompitible with this software.

More details regarding NCSARGEN are covered later, as will the file
NCSARSIM.INI that NCSARSIM uses to know exactly how to run NEC and where
to find its output data.  First, NCSARSIM's inputs and processing are
discussed further.

The DOS command to run NCSARSIM is


NCSARSIM filename


where "filename" is the name of the master NEC input file referred to
above.  (As mentioned above, if you don't specify a command-line argument,
NCSARSIM will ask you for the name of the file.)  Unless your version of
NEC requires it, whether or not you change to the disk/directory where
NEC resides is up to you.  Neither NCSARSIM nor any software associated
with it will invoke such a change.

NCSARSIM inputs various information from you via prompts to the screen.
The first such input is for the beginning and ending frequencies (Mhz),
and the number of frequencies you want NEC to process.  These are all
specified in a single line of input, and like all inputs to NCSARSIM where
more than one parameter is typed on a line, there must be commas between
the parameters.  The largest number of frequencies you should input here
is 512.  A larger value will be reset to that value.

NCSARSIM then asks you for the beginning and ending azimuth angles
(degrees), and number of azimuths that NEC is to process.  (If you are
going to be simulating a linear SAR, *and* performing stabilized scene
polar interpolation, the angles input here should be between -90 and 90
degrees.  The maximum number of angles allowed is 256.

As alluded to above, NCSARSIM next asks you whether you want to simulate a
circular SAR, i.e., a SAR that generates data by flying on a circular arc
about scene center (NEC's coordinate origin), or a linear SAR--the
traditional case where the SAR flies along a straight line.  ("C" means
circular SAR and "L" means linear SAR.)

NCSARSIM next asks you for information concerning where the SAR is.  How
it does this depends on whether you said previously to use a circular or
linear SAR.

First, let's say you said to use a linear SAR.  When you choose this
option, the SAR is taken to fly along NEC's y-axis.  If the image is
formed in NEC's fixed coordinate system, that's called stabilized scene
processing.  If a coordinate system local to the SAR is used to form the
image, that's called line of sight processing.  Whether NCSARGEN is to
make a stabilized scene or line of sight image, NCSARSIM's prompt here is
for the "stabilized zenith angle" (degrees).  This is the complement of
the elevation angle the SAR would have when it's at NEC's 0 azimuth angle.
(It does not matter whether or not the SAR ever actually gets to this
point.)

Again only for a linear SAR, NCSARSIM next asks you for (on a single line
of input) the SAR's speed (m/s) and stabilized down range (km).  (Stabil-
ized down range is a lot like stabilized zenith angle.  Stabilized down
range is the SAR's x coordinate in NEC's fixed coordinate system.)

Okay, let's say you said to use a circular SAR.  NCSARSIM's inputs in this
case are the SAR's (fixed) zenith angle (degrees), and then for (again on
a single line) the SAR's speed (m/s) and orbital radius (km), i.e., the
radius of the circle that it flies on.

After that decision-making is done with, NCSARSIM asks you for the polari-
zation angle (degrees).  Perhaps the best way of explaining this angle is
simply to point out that it is the "eta" parameter of NEC's EX card when
that card's "I1" parameter = 1.  (The SAR scene is taken to be illuminated
with a linearly polarized wave.)

NCSARSIM next prompts your for whether you want theta (vertical) or phi
(horizontal) polarized fields output.  Inputting an integer 1 means theta
and 2 means phi.

Now we get to details about how the target is moving.  First, by "target,"
it should be clear that the meaning is the complete set of wire segments
in NEC's geometry file between the value of ITS input above and the blank
GM card.  (Other wire segments are part of the target too, but since they
aren't involved in the motion, they aren't explicitly considered here.
The target may be moving rectilinearly along a line in the xy-plane in any
specifiable direction (at constant speed).  The target may be rotating
about any specifiable axis, or it may be vibrating about any specifiable
point, with the axis of vibration at any specifiable angle to the x-axis.
The rotation need not be in a fixed direction.  The rotation can be in the
sense of a torsional oscillation.  The axis of rotation/torsion may be
rectilinearly moving, as may be the point of vibration.  (Actually, the
point of vibration isn't necessarily a single point if more than one wire
segment is involved.  Each segment vibrates about it's initial position
specified in the master NEC file.  The point(s) of vibration may be rotat-
ing about some axis--the same point otherwise specified as the axis of the
target rotation.  In this case, the axis of vibration rotates with the
particular wire segment.

That digression hopefully makes the following discussion of the motion-
related inputs to NCSARSIM more coherent.  The first such input is for the
target rotational rate (rotations per minute (rpm)).  Input 0 if the
target isn't rotating in a fixed direction.  NCSARSIM will take this zero
input as justification to ask you about a torsional oscillation of the
target.  In that situation, it asks you for the torsional oscillation
frequency (hz) and amplitude (degrees).  (A zero amplitude will cause
whatever you might have input for the frequency to be taken as zero.)  If
you input a nonzero rotational or torsional frequency, NCSARSIM will next
ask you for the xyz coordinates (m) of the rotation axis.  This is any
point that the axis of rotation passes through.  It then asks you for the
xyz direction cosines of the rotation axis.  NCSARSIM normalizes these
quantities internally so that the vector they correspond to has a magni-
tude of unity.  Whether or not you input them that way is up to you.  (If
you input all zeros for these three quantities, NCSARSIM will translate
your input so that the rotation is about a vertical axis.)  The
directional reference for these quantities is such that the rotation is
defined in the righthand sense.

NCSARSIM next asks you for the x and y components of the target's velocity
(m/s).  Linear velocity is implicit here.  Feel free to enter 0s here if
the target isn't moving at any constant speed along a straight line.
(There are no inputs, by the way, for initial positions in regard to any
of the types of motion.  This data is taken to be that at the start of the
SAR collection, i.e., at the first azimuth angle considered by NEC.  (It
should be clear that the link with time here is that each azimuth angle
corresponds to a different time.))

NCSARSIM next asks you for the vibration frequency (hz).  If you don't
input 0 (for no vibrational analysis), NCSARSIM then proceeds to prompt
you for the vibration amplitude (mm) and angle of vibration (degrees).
This angle is with respect to the x-axis.

Except for for a couple of minor nitpicking details, you only have one
more input to go.  That input is for that tag number mentioned above indicated the first
wire segment in your master NEC input file that is involved in the motion.
(This is the GM card's "ITS" parameter.)

The first of those nitpicking details relates to how NCSARGEN generates
the image.  In addition to writing scattered field data from NEC to the
file created by the PL card, NCSARSIM writes some other types of data to
SARRUN.NEC.  If you wish to look, you will see this data in the first six
lines of CM cards.  These cards will preceed whatever comment cards you
originally had in the master NEC input file.  This is a mechanism for
NCSARSIM to transfer data to NCSARGEN.  The second of these CM data lines
contains two numbers relating to how big the image generated by NCSARGEN
is to be.  This choice quite often depends on how you're going to display
the image produced by NCSARGEN and what capabilities your display device/
software has.  NCSARSIM attempts to look at your video adapter and
determine what your video system can do.  In doing this, it takes into
account the fact that the auxiliary program VCI is going to be used to
display the image.  (VCI is discussed later.)  It first looks for an 800
x 600 x 256 video mode.  If it can't find that, it looks for a 1,024 x 768 x 256
mode.  Finally, if that fails, it moves backwards and looks for a 640 x
480 x 256 video mode.

If NCSARSIM detects the appropriate video mode, you're done inputting
stuff to it (but not to NCSARGEN) unless it needs the above mentioned
information for creating NCSARSIM.INI.  However, if it fails, it will
simply ask you what resolution video mode you want the image to be made
to fit in.  (This prompt occurs after the input for ITS but before you're
asked about information relating to how your version of NEC operates.)
Your choices here are an 800 x 600, 640 x 480, or a 320 x 200 mode.  These
choices may seem a little strange.  What happened to the 1,024 x 768 mode
mentioned initially?  NCSARSIM only looks for that mode in case your image
would need an 800 x 600 mode but NCSARSIM couldn't find such a mode.
NCSARGEN at no time makes an image that requires more than an 800 x 600
mode.  But what's that 320 x 200 thing about, you ask?  Well, there's
another auxiliary program supplied here--vMOVIE.  As discussed later, if
you tell NCSARGEN to do dynamic imaging, you can use VMOVIE to display the
successive images in a movie-type fashion.  However, VMOVIE just recently
acquired the capability of displaying images in anything higher than the
320 x 200 mode.  That higher resolution capability is not guaranteed to
work in such higher resolution video modes on all computers (but I think
it should as long as their video system supports VESA).

If you determine that your video system is not compatible with VMOVIE in
its high resolution mode, even though NCSARSIM autodetects the presence of
such a video mode, and you know or believe that the 320 x 200 mode should
be large enough, you have a way of forcing the issue.  Before you run
NCSARSIM (you only have to do it once since opening the DOS window), do
do the following from the DOS prompt:


SET SCREEN=13


This tells NCSARSIM to tell NCSARGEN to make the smallest image it might
generally consider making.  What are the image sizes NCSARGEN makes,
depending on the video mode?  The 800 x 600 mode is associated with a
512 x 512 image, the 640 x 480 mode is associated with a 512 x 256 image,
and the 320 x 200 mode is associated with a 256 x 128 image.  (The first
number refers to down range pixels and the second one refers to cross
range.)  Of course, if your video system is such that NCSARSIM cannot
auto-detect a suitable video mode, then you don't have to worry about this
due to the above mentioned prompt for what video mode to use.

At this point, NCSARSIM proceeds to generate SARRUN.NEC, the actual input
file that NEC is going to be run with.  It displays the azimuth angle that
it's processing data for at any given time.  After that file is created,
NCSARSIM would generally run NEC and then NCSARGEN.  (It runs both
programs via a SARRUN.BAT file that it creates.)  However, before doing
that, it makes sure it knows how to run NEC bringing us to the second of
those "nitpicking details" mentioned above.  It makes that determination
by looking for a file NCSARSIM.INI in whatever your current directory is.
Obviously, if you've never run NCSARSIM before, that file isn't likely to
exist in any directory (and if it does, it won't be for use by NCSARSIM).
So, the first time you run NCSARSIM from within any specific directory,
NCSARSIM needs to create that file (in that directory).  It prompts you in
that situation for two file names.  The first is for the name of your NEC
executable.  You do not need to include the ".EXE" extension.  Whether or
not you include path inforation in front of the name (e.g.,
C:\NEC\NEC2D2K8) depends on whether you need or want to.  You are then
prompted for the name of the file that NEC's PL card creates.  NCSARSIM
then creates NCSARSIM.INI and you shouldn't need to go through that
process again as long as you run NCSARSIM from that directory.  (This is
one reason why you might want to always switch to a specific directory
(NEC's, perhaps) before running NCSARSIM.  One situation that could cause
you to need to go through the process again is if you want to change which
version of NEC you're using.  One way of doing that is simply to edit
NCSARSIM.INI (it's just a text file).  The other way is simply to delete
it and let NCSARSIM create it for you.  (Another situation that will cause
NCSARSIM to go through the process of creating NCSARSIM.INI again is if
it can't find both lines of data in that .INI file.)

When NCSARSIM finishes what it needs to do, it runs your version of NEC
and then NCSARGEN is automatically run in order to generate the image from
the data stored in the PL card's output file.  NCSARGEN has its own set of
inputs.  Some of them it gets from SARRUN.NEC, as already mentioned; you
don't have to worry about those.  It first shows you a choice of spectral
windowing functions to use and then lets you input an integer between 1
and 15 to choose the window.  If you choose a taylor window, NCSARGEN will
then ask you for the sidelobe level (dB).

Before continuing, some explanations are in order.  NCSARGEN is a
derivitive of other SAR processing SW I've written.  I left most of the
program options in place, even though they don't necessarily have much
interest to someone merely trying to see what different types of target
motion do to images.  So, you'll have to bear with having to specify
inputs for things you probably can't care less about.  Also, like
NCSARSIM's needing input delimiters to be commas, NCSARGEN has its own
quircks.  Although it doesn't care whether you use commas or spaces
between multiple inputs on the same line, you have to be careful about
giving it a floating point value when it expects an integer.  (In other
words, if it's expecting a 0 or 1, don't input "0." or "1.")  Hopefully,
the context of the input prompt will make it clear what type of number it
wants, but the variable type will be mentioned in the discussions, at
least where it really matters.  (The window type input above is an example
where a floating point value would have no meaning and only generate an
error.  Also, if you do get an error and the program terminates
prematurely, just run NCSARGEN over again.  The procedure for doing that
"manually" will be described eventually.)

NCSARGEN's next input is for a rather archane sounding quantity--a
spectral threshold factor.  NCSARGEN uses this to exclude low-level
spectral values from consideration.  This in turn tends to exclude bright
point sources from the image.  (The presense of strong scattering returns
from motionless sources in the imaged scene tends to bias the centroid
calculations.)  Do not input 0 for this quantity.  If you want to include
all spectral values, just input any negative quantity, or a very large
positive value.  (If you aren't going to include a second field file
containing static scattering data (see later), you might as well just
include all spectral values.  I haven't done a lot of experimenting, but
if you *are* going to exclude low-level spectral values, this input should
be rather small, say 2 or less--the smaller the number, the more the
thresholding.)  Alternatively, especially for using dynamic imaging and
centroid analysis for scenes containing target motion, you may want to
include all spectral values and use imaging thresholding, as discussed
below, to exclude strong scattering returns (which are usually from static
targets).

NCSARGEN next prompts you for the number of points to use in an azimuthal
moving average.  Clearly, this should be an integer, and you'd generally
want to input 0 for it so no moving averaging occurs.  (If it does occur,
the moving average is applied to the input polar data along azimuth for
each frequency.  Again, this is just here because I was interested in
studying something.)

NCSARGEN then gives you a prompt for the image resolution.  Input an
integer 2 here.  (VCI won't display the type of image you get with options
0 or 1.)

NCSARGEN's next prompt is for an integer 0 or 1.  The former causes
NCSARGEN to use LOS polar interpolation and a 1 results in stabilized
scene polar interpolation.

If you specified LOS polar interpolation, NCSARGEN next asks you whether
you want a slant plane image (or images) or a ground plane image.  An
integer 0 input means slant plane and a 1 means ground plane.  (If you
specified stabilized scene interpolation, you're going to get a ground
plane image.)

Two or three more inputs and you're home free.  NCSARGEN next displays how
many azimuth angles it has to process and asks you how many you want to
include in each dynamic image.  (The same number is used in each image.
This is clearly an integer value.)  This input should be at least two but
not more than the number NCSARGEN shows you for the total.  If you input
the total value, NCSARGEN makes just one, static, image.  If you input a
lesser number, thus instructing NCSARGEN to do dynamic imaging, it also
asks you for how many azimuth angles you want to overlap successive
dynamic images by.

NCSARGEN next asks you for two image threshold factors.  The first of
these is used to exclude low-level "background noise" in its calculation
of the image centroid components.  The second factor is used to exclude
very bright scattering centers from the centroid calculations.  The larger
the particular value, the less the respective thresholding.  If you want
to eliminate thresholding for either the low or high values, and include
all low or high scattering centers, input a negative value for the
respective threshold factor.  I usually input 50 for the low threshold,
but you can experiment with whatever other (floating point/real) value you
want.  The high threshold may require a significantly smaller value, e.g.,
5 (or even less--but more than one).  (Going less than 10 for the low
threshold might be extreme, but you're the one running the program.  And
again, don't input 0 for either of these parameters.  This prompt is
skipped if dynamic imaging isn't being performed.)

After inputting the data, NCSARGEN calculates the range and cross range
sampling intervals/stepsizes (whatever you want to call them).  If they
aren't close enough to be considered equal, it asks you if you want them
to be made equal.

NCSARGEN then proceeds with its processing, outputting informational
messages along the way.

After a (hopefully) brief discussion of NCSARGEN's outputs, discussion of
NCSARGEN itself is dispensed with.  In addition to outputting a static
image to SAR.BIN or dynamic images to SAR.1, SAR.2, SAR.3, ..., as
discussed above, as well as the centroid components for dynamic imaging,
NCSARGEN also, again only for dynamic imaging, calculates the second
moment of the images as a function of time and outputs it to the file
MOMENT2.TIM.  (This was another experiment just to confirm that it isn't
particularly useful, at least for the analysis of rotating targets.)  For
static image generation, NCSARGEN generates an "SPLOT command file."  This
file stores data to be used with the program Screen PLOT to plot the
image's cartesian spectrum as a 2-D function of wave vector components.
(In spite of the file name being PHASE.PLT, the plot gives the magnitude
of the spectrum, not the phase.  The name arises out of my initially
erroneous belief concerning the meaning of the term "phase history.")  The
Screen PLOT software is included here, but not otherwise discussed.  (See
SPLOT.DOC in the archive.  Let me know if you want the Windows version.)

As promised, let's say you want to run NCSARGEN over again, after it's
already been run automatically by NCSARSIM, perhaps because you want to
specify different inputs.  The command-line syntax is


NCSARGEN SARRUN.NEC PLFILE


where "PLFILE" refers to the file that the PL card creates with your
version of NEC--or whatever you may have renamed that output file to from
the last use of NCSARSIM.  Make sure whatever file you specify here
actually corresponds to an output of NEC as controlled by NCSARSIM.
SARRUN.NEC is of course the NEC input file that NCSARSIM created.  If
you've renamed that file since running NCSARSIM, use that name instead of
"SARRUN.NEC."

Okay, that should cover NCSARSIM and NCSARGEN.  Let's discuss the use of
VCI to display NCSARGEN's images.  The syntax for running VCI with an
image file SAR.BIN, for example, is


VCI SAR.BIN


(Don't forget to include the image file name on the command-line.  VCI
won't prompt you for it.)  VCI first checks to see if you have a rodent
installed.  If you don't, it asks you if you want to continue or termi-
nate.  If processing is allowed to continue, it shows you a list of video
mode resolutions and asks you which one represents the maximum your
computer can handle.  VCI bases its actual decision on what video mode
to use on the image file and what video mode it can auto-detect.  So, in
an ideal world, the input you're being asked for doesn't seem necessary.
However, it may be that your video card supports the necessary video mode,
but your monitor doesn't.  So, I put in this input to better control
things.  You only have to press a number for the integer response it
wants; you don't have to press ENTER.  (Generally, you should NOT press
ENTER here; VCI clears the keyboard buffer in case you do.)

After inputting that integer, VCI proceeds to load your image data into
(virtual) memory and then displays it.  Once the image is on the screen,
it may be worthwhile to point out that down range is to the right and
cross range increases upwards.  (The SAR is imagined to fly vertically
upwards, along the righthand side of the image.)  There are a few things
you can do once the image is on the screen.  (VCI beeps to let you know
it's finally done getting the pixels on the screen.)  Generally, you get
control of the different program options by pressing a key.  However,
don't just press keys at random.  Most keystrokes simply terminate the
program and clear your screen.  The data on the screen are pixel
attributes from 0 to 255.  If you press a sequence of 3 numbers (and don't
press ENTER!), VCI takes that to be a pixel threshold and repaints the
screen, showing only pixels with attributes higher than the threshold you
typed.  (If you wish to specify a threshold less than 100, you have two
options.  You can just press the 1 or 2 digits and then press ENTER or you
can preceed the one or two nonzero digits with up to 2 zeros, depending on
how many you need to get 3 total keystrokes.)  You have one more way of
setting a threshold.  If you press "T", a rodent cursor will appear--if a
rodent driver is installed.  (If a rodent driver is not installed and you
told VCI to continue anyway, "T" will just terminate the program.)  Move
it around and (left) click on a pixel.  All pixels with attributes greater
than or equal to that attribute will then be displayed when VCI is done
repainting your screen.  (Again, it always beeps when it's done painting
the screen.)

If you press "M", VCI will turn a rodent cursor on again.  You can use
this particular feature to measure distances between two points.  Move the
cursor to the first point and left click.  Then move the cursor to a
second point and left click.  The distance between the two points will be
displayed at the top of the image.  You can then repeat this process for
another pair of points.  Right click to get rid of the cursor and quit
"distance measuring mode."

You can toggle the image pixel display between logarithmic and linear
scaling by pressing "L".

If you press "R" or "C", a rodent cursor again appears.  You can use this
feature to output complex image sequences.  Move the cursor to the row
(down range) or column (cross range) that you're interested in and click
on it.  (It shouldn't matter which rodent button you press.)  If you
pressed "R" (for row) to get into this mode, the row's complex image
sequence will be output to COMPLEX.ROW.  If you pressed "C" (for column),
the column's complex image sequence will be output to COMPLEX.COL.  The
format of each file is the same.  The first line gives the sample interval
between image pixels and next follow the real and imaginary parts of the
sequence.  (After pressing the rodent button, VCI automatically generates
the file and then exits this mode.)

CI has two more features that you might conceivably be interested in.  If
you press "S", VCI will save the image to the file IMAGE.GET in what I
call QuickBasic's "get format."  What do you do with that image?  Well,
you can use the utility VDISPGET to display it again, for whatever reason
you'd want to do that.  (VDISPGET doesn't have any of VCI's rodent
features.)  If you're interested, let me know and I'll give you a utility to
transform IMAGE.GET to a PCX file.

(If you press E, A, or O, and a rodent driver is installed, termination
does NOT occur.  Rather, a rodent cursor appears which you can use to draw
boxes around areas in the image.  You can get more information about these
features from the commentary at the top of VCI.BAS.  They aren't real
important to using VCI with NCSARSIM.  I only mention them so you don't
get confused when something "weird" occurs when you press one of these
keys.  If you press E by mistake, just press and release any rodent button
and then, when you're done using VCI, delete the extraneously created
PORTION.BIN file.  If you press A by mistake, press ESCape and then press
and release the LEFT rodent button.  If you press O by mistake, just input
0 when it asks you for the height and you'll be returned to the normal
display mode--you'll need to click (and release) a rodent button before
getting that prompt.)

If you press D, a DOS command shell is started.  You can use that if you
need to execute some DOS command (such as renaming a file created by using
CI's E or Z option).  Type EXIT to return to the image displayer.

VDISPGET was mentioned earlier.  Before using it, you need to set a DOS
environment variable:


SET SCREEN=VESA


(Not defining SCREEN at all, or setting it to 13, should work if the
picture fits in mode 13's 320 x 200 screen size.)

There's one more utility to go, VMOVIE, and it has no utility to you if
you didn't tell NCSARGEN to do dynamic imaging.  The syntax for VMOVIE
is


VMOVIE ND


where ND is the number of dynamic images.  It then loads the image data
from SAR.1, SAR.2, SAR.3, ..., SAR."ND" into (virtual) memory and then
displays the images in "movie fashion."  If you press any key but F1,
VMOVIE will terminate when it gets to the end of the sequence.  (Other-
wise, it just repeats from the beginning when it gets to the end.)  If you
press F1, VMOVIE goes into "single frame mode."  Here, it displays a
single image until you press a key.  But don't press ESCape; this termi-
nates the program immediately--in *this* mode.  Pressing F1 again resumes
"movie mode."  (So, if you're in movie mode and you don't want to wait
until the end to terminate, press F1 and then ESCape to terminate *right
now*.)

How do you know what ND is?  Well, let NT be the total number of azimuth
angles that NCSARGEN told you about in the process of asking you how many
azimuth samples you wanted to use for each dynamic image.  (It's the same
number you input to NCSARSIM.)  Let the number of azimuth samples in this
subset of the total be NS:


ND = NT - NS + 1.


At no time will NCSARGEN allow ND to exceed 300, however.  Whether or not
VMOVIE will work with that many images depends on whether DOS (whether it
be the real DOS, after booting into it, the the emulated DOS in effect
while in a DOS window under Windows), has a sufficient number of file
handles available.  In "real DOS," you may need to increase the FILES=
parameter in your CONFIG.SYS file.  If Windows is active (the likely
case), you may need to adjust the PerVMFiles= parameter in the [386Enh]
section of your WINDOWS\SYSTEM.INI file, or add such a line.  (VMOVIE will
tell you if you need to do this.)

There is one more option for making a movie of your dynamic images.  Let's
say, for example, that you want to use "Windows Movie Maker" (a Microsoft
product for Windows).  That program lets you import BMP files and then you
can have it display those pictures as a movie, and then save that movie in
a .WMV file (and then perhaps distribute it as you wish without the
recipient having to have VMOVIE and having to run it from DOS or in a DOS
window).  Now, those SAR.* files aren't BMPs.  Not to worry.  The included
utility SARBMP will convert all those files to BMPS.  It's syntax is the
same as VMOVIE's:


SARBMP N


where N is the number of BMP files to make.  (Like VMOVIE, N must be at
least 1 and not larger than ND--but SARBMP will allow up to 999 files.)
The BMP files will be named SAR001.BMP, SAR002.BMP, SAR003.BMP, ...,
SAR"N".BMP.

Note that SARBMP only works with individual dynamic images.  It will NOT
work with the complex image file you get if you tell NCSARGEN to make a
static image.  If you want to make a BMP file from that image file, use
SAR2BMP.  The syntax is


SAR2BMP filename


e.g.,


SAR2BMP SAR.BIN


The output file is named SAR.BMP.  (You might want to be warned that the
"macro utility" SARBMP will destroy any such file that you might have made
beforehand.)

Another reason that you may wish to use SARBMP and SAR2BMP is if you're
using Win2K/XP/NT.  Unless you do a "SET SCREEN=13" before running VCI and
VMOVIE, and your images will fit in a 320 x 200 window, these programs do
not appear to work with versions of Windows "above" WinME.  If you're
using such versions of Windows (highly likely), you will need to use
SAR2BMP or SARBMP in order to make images that you can look at.

Okay, what's in the archive?  In addition to the file you're currently
reading, when you unzipped NCSARSIM.ZIP, several other .ZIP files appeared
on your hard drive.  The executable files already discussed are in
EXECUT.ZIP.  The source code is in SOURCE.ZIP.  That archive and
VCILIB.ZIP also contain some auxiliary routines necessary for compiling/
linking the source code, should you ever get inclined to do that.  (The
source code for Screen PLOT isn't available.)  Here's what you do
with it.  Unzip at least EXECUT.ZIP to some directory on your hard disk.
Unzip Screen PLOT (SPLT786.ZIP) archives either to this directory or to
whatever directories you want (if you want to use Screen PLOT).  The
DOSXMSF.EXE file is a special file containing the DOS extender needed by
NCSARGEN.  It either needs to be in your current directory or in a pathed
directory.  (Other than making sure NCSARGEN.EXE can find that file, you
don't need to do anything in particular with it.)  Unless you plan on
never using the option to shell to DOS while running VCI, make sure
sure RAMFREE.EXE is in a pathed directory as well.

RAMFREE.EXE is a utility to tell you how much conventional memory you have
available.  VCI suggests that you use it when you use its Y option to
spawn a DOS shell.  (If this sofware was distributed on disk, there is no
NCSARSIM.ZIP.  The floppy just contains the other archives mentioned.  If
you received the software on CD, there aren't any archives at all.  There
are just subdirectories on it named as the above mentioned archives, with
this text file being in the root directory.),

Finally, there's a few set-up details that I didn't discuss above.  And if
by some chance you're using this software in "real DOS," i.e., Windows
isn't running, you can ignore this.  However, if you want NCSARGEN to work
with Windows running, keep reading.  The WINDOWS.ZIP file contains some
driver files that you need in order for NCSARGEN to run in a DOS window.
These files are DOSXNT.386, MMD.386, and DOSXNT.EXE.  Like DOSXMSF.EXE,
just make sure DOSXNT.EXE is either in your current directory or at least
a pathed one.  The two ".386" files need to be referenced in the [386Enh]
section of your \WINDOWS\SYSTEM.INI file.  The syntax is


device=c:\f32\bin\dosxnt.386
device=c:\f32\bin\mmd.386


(NCSARGEN works with WinME and "lesser" versions of Windows, as long as I
make the above change to my SYSTEM.INI file.  Although I haven't tested
it, I don't see why it shouldn't work with Win2K/XP/NT.)  The PerVMFiles
parameter mentioned above also goes in this same section of SYSTEM.INI.
The syntax is

PerVMFiles=N

where N is the maximum number of file handles that you want to allow.
N = number of allowed dynamic images + 10 appears to work okay.

Well, okay, that wasn't quite final.  Perhaps I should go over some mathe-
matical details.  First, I've typically been taking the SAR down range
distance/orbital distance (r) to be 10 km and the SAR speed (v) to be 100
m/s.  You can use whatever you want, but these choices seemed convenient
and generally allow moving objects to stay within NCSARGEN's limited image
size.  These choices, along with the azimuthal extent of the SAR's path,
also affect the time between simulated SAR pulses.  This in turn may
affect the inputs you use for the target kinematic inputs.  Using the same
NT as before for the total number of azimuth samples, the time between
pulses for a linear scene SAR is


dt = r * (tan(phi2) - tan(phi1)) / v / (NT - 1),


where phi1 is the beginning NEC azimuth angle and phi2 is the final NEC
azimuth angle.  For a circular SAR, dt is almost the same--just remove the
tangent functions.

Enjoy yourself.  Feel free to email me if you have questions, need help
with SPLOT or the other programs, whatever.

-Glenn Stumpff
gstumpff@yahoo.com
