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. 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. 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 (extended) 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 (extended) 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 come bug me if you have questions, need help with SPLOT or the other programs, whatever. -Glenn Stumpff gstumpff@yahoo.com