Intern Report: Christian Fischer
Intern Report: Christian Fischer
This report gives a short view of my
Summer Internship
July 5th to October 13th
at the
Alaska Satellite Facility (ASF)
Geophysical Institute
University of Alaska Fairbanks
Fairbanks, AK 99775-7320 USA
Table of contents
The Alaska SAR Facility The Alaska SAR Facility is a branch of the Geophysical Institute of the University of Alaska Fairbanks. The data of the spaceborn SAR (synthetic aperture radar) systems like the european ERS 1 and ERS 2, the japanese J-ERS 1, and the canadian RADARSAT is received here, processed and users provided with SAR images.
The data is received using a 10 m antenna dish on top of the building (soon another 11.5 m dish will be installed), demodulated and stored on very fast (105 MBit/s) high density digital recorders. Then the images are processed by the SAR Processor System and stored into a database. The images can either be given directly to users or can be used for the Geophysical Processor System of the Geophysical Institute for further processing to get information about e.g. sea ice movements or glaciology out of the images.
- Basics on SAR Principles
- Calibration
- Introduction to the RADARSAT-Spacecraft
- The RANDI Software
- General Discription
- RANDI Modifications Compared to ANDI
- RANDI Start and Command Line
- RANDI Main Program
- Open Questions
- How to Modify the ANDI/RANDI Software
- Trouble with RANDI
- DRD Interface Functions
- Tools
- The DX-Display Program
- The Motif-Toolkit
- Conclusion
- Useful Literature
Basics on SAR Principles
The SAR (synthetic aperture radar) principle allows earth observation with an active device (so it is independent from daylight) at a wavelength that penetrates clouds without disturbances.
The resolution in range is restricted by the beamwidth and the length of the transmitted radar pulse, so the goal is, to get a short but as powerful as possible pulse. In modern SAR Systems a pulse compression is used to solve this problem. The along-track resolution is restricted by the aperture of the antenna, at the wavelength used by the SAR the antenna would have to be really huge to get something you could call resolution. In order to get a good resolution using an antenna with a reasonable size (e.g. 10 m) the SAR principle was developed, which represents a cooperation of radar and signal processing technologies. The SAR principle uses the movement of the radar system relative to the target to accumulate information over many radar pulses.
The information used by the SAR Processor to locate a point target is its so called doppler history, which is the variation of thedoppler frequency of the target as the satellite passes it.
An interesting point is that the best possible resolution of a SAR always equals half of the antenna aperture and is independent of all other parameters of the system (like wavelength or distance to the target).
[return to top]Calibration
Three different kinds of calibration are usually used for SAR devices:
a) geometric calibration is used to make sure, that the location of targets in the SAR images match the real (geographic) location.
b) radiometric calibration is used to ensure an accurate measuring of the back scattering of the targets. Knowledge of the backscattering characteristics of a certain target allows one to gain a lot of additional information. Different error sources disturb radiometric calibration, e.g. athmosperic effects on the waves (like attenuation of the signal, group delay - low frequency high altitude, polar orbiting SARs - or rotation of the polarized wave) or distortions of the antenna pattern. The rms distortion of the antenna pattern must be less than /8, considering the spaceborn environment with large variation in temperature a difficult goal. Another problem is that the characteristics of the antenna cannot easily be measured by internal calibration. Internal calibration means that test signals are injected into the receiving process by built-in devices. In addition, external calibration characterizes the system performance using calibration signals originating from ground targets(e.g. corner reflectors, transponders).
c) pulse calibration is used to match the range compression algorithms with the pulse characteristics. This is important to get a good point target quality (resolution).
[return to top]Corner Reflectors
The ASF calibration/validation department uses trihedral corner reflectors (shown below) for location and radiometric calibration.
Just recently the ASF got a set of four new reflectors, according to the increased number of satellites received in Fairbanks and the wish to be able to do more radiometric calibration. These corner reflectors are a little bit different in design, which results in reduced weight with nearly unchanged backscattering cross-section. While it is very hard to change the direction of the old reflectors, the new ones can be redirected in minutes thanks to a new base construction.
Two groups of reflectors are in use, one group is located north the arctic circle and is maintained once a year, the other reflectors are near Delta Junction. These are maintained about once a month; after the start of a new satellite even more often.
The corner reflector has to be directed towards the satellite during its pass with an accuracy of about 5 degrees. The image shows the location of the reflectors in the Delta field:
DJ7, DJ11, DJ13 and DJ15 are the new reflectors.
[return to top]Introduction to the RADARSAT-Spacecraft
This SAR Satellite will be launched in September 1995. It is a project of different organizations like the Canadian Space Agency CSA and the NASA. The spacecraft will orbit at an altitude of about 800 km and uses C-band (about 5.3 Ghz) to image the earth.
[Copyrighted image of the RADARSAT spacecraft removed - Ed.]
The spacecraft is able to work in different modes, for example a ScanSAR mode observing a 500 km swath or different fine resolution modes covering a swath of 50 km and providing a resolution of 10 m.The table gives an overview over the different beam modes:
The beams are located over the swath as shown in the graph The data will be transmitted to the ground stations by using the X-band. The data shall be used for different purposes, e.g.
-Agriculture
-Crop Assessment: Determination of crop type and area. Assessment of vegetation biomass or crop damage.
-Compliance Monitoring: Assessment of farming activity (tilled/cropped land)
-Land Use Monitoring
-Soil Condition Monitoring: Assessment of soil moisture and erosion
-Cartography
-Base Mapping: terrain form, land use, land cover, cultural features
-Topographic Mapping: terrain elevation, XYZ coordinates (collection of stereographic SAR images for mapping)
-Coastal Zone
-Coastal Zone Mapping, like land-water boundaries
-Ship Detection and Monitoring (illegal fishing)
-Oil Spill Detection
Sea Ice
-Creation of daily Sea Ice Maps
-first comprehensive map of the Antarctic continental ice sheet based on SAR images
-Forestry
-Identification of general forest classes
-Deforestation Mapping (forest disturbances)
SAR data can be ordered as film/print product or in digital form (e.g. as processed Map Image or just as raw data).
[return to top]RADARSAT X-band specifications
The X-band communication consists of two downlinks with transmission data rates of 105/85 MBit/s. For each radar pulse (represented by one format) the data is divided into frames, the number of frames is dependent on
- presence/absence of replica data
- the ADC sample rate
- duration of the receive window.
This makes one of the main differences compared to ERS 1, where the number of frames is fixed to 29. The image shows the structure of a RADARSAT Frame and the length of the different fields in Bits.
The format structure at RADARSAT is shown in the following graphic:
Each frame consists of a 10 Byte header, including a synchronization marker, frame identification (real time or stored frame),master and virtual channel frame counter and the frame data field status indicating valid or not valid data.This header field is followed by the application data field, containing auxiliary, pulse replica, echo or fill data. The data in this field is scrambled by a pseudo random sequence (using XOR) in order to avoid unfavorable bit patterns and to ensure an adequate number of bit patterns for synchronization. The pseudo random sequence is created by a 8 Bit shift register.
The first frame of the pulse always contains auxiliary data (50 Bytes), giving various information about the operational status, current beam mode, spacecraft temperatures, ephemeris data, receiving window and many other details. Each 8th pulse the auxiliary data is followed by the samples of a pulse replica, allowing control of the transmitted radar pulse. Afterwards the echo data (4 Bit samples representing the range of -7.5 V - +7.5 V) follows, the last frame of the pulse usually has to be filled with zero bytes in order to satisfy the fixed application data field length of 311 Bytes. At the end of each frame follows a frame error control field of two bytes containing a check word. This check word is performed over the entire frame after scrambling the data field, excluding the frame synchronization marker and the check word itself. It allows to indicate errors in the transmission.
[return to top]The RANDI software
[return to top]General description
The RANDI software is a modification of the ANDI software, which was designed to handle raw data transmitted from the satellite ERS 1. RANDI provides the same functions as ANDI but handles raw data of the RADARSAT satellite. My task was to program RANDI using the ANDI Software. Because of differences in the downlink transmission format and the provided raw data of the two satellites many modifications had to be made. What do RANDI/ANDI with the raw data of the satellite? The data is extracted and different data types (like data of radar echos, auxiliary data or sampling data of radar pulses) are stored in files for each type. These files follow a certain satellite independent format, which is called the DRD (Decoded Raw Data) library format. In addition, a so called report file is created where the user can find various information about the program execution and the processed raw data, like the file size, if the data is corrupted in a way or other more or less interesting stuff. After processing the raw data with RANDI/ANDI, various tool programs can analyze the data of different spacecrafts by using the DRD library. These tool programs e.g. calculate histograms over the echo data or show the fourier transformation of a pulse chirp.
[return to top]RANDI modifications compared to ANDI
The usage of the RANDI Software (RADARSAT) is the same as for ANDI (ERS 1), so the ANDI power user will be able to switch easily to RANDI. A few differences between the two programs in short:
1) RANDI doesn't know noise or calibration pulse data, because this data doesn't exist for RADARSAT. Therefore no .cal or .noise file will be processed. The output files of RANDI (.echo, .aux, .zero, .rep, .report) follow the standard of the DRD library.
2) A switch "-a" was added to the command line parameters. This switch activates the so called "CareFree" mode, which means, RANDI will not check format and frame counter values found in the raw data. This might help to process data that is disturbed a lot, in order to gather at least a little bit of information. This mode should be used only if really necessary (e.g. in case RANDI cannot process any scans at all out of the raw data file)! The results might be unreliable!
3) After the start of RANDI a time estimation for the processing time was added (it gives only reasonable results when Randi is the only application running on the Sparc 2 and is working in the default settings), also during the program run there occurs a display showing how many percent of the work have already been finished.
4) The difference between "image formats" and "formats" isn't made in the RADARSAT version anymore, each format represents one scan (samples of one radar pulse).
5) RADARSAT provides only a one byte counter for the format, it is free running, so after format 255 the counter is resetted to format 0. This would result in ambiguities of the stored image scan numbers which are identical to the format counter values of the scans. Furthermore, most of the tools don't handle DRD data where the image scan numbers are not continuously upcounting. To avoid these problems, RANDI detects when the spacecrafts format counter goes over 0 and then increments a three byte software counter (called "SerialCounter"). It calculates the image scan numbers (4 bytes) by using the spacecraft counter as last byte, the serial counter as first three bytes. This results in image scan numbers that are always upcounting and the original (hardware) format counter of the spacecraft can still be gained by extracting the last byte or calculating modulo 256 of the image scan number.
6) To detect, how much data was lost when the raw data is disturbed the spacecraft time is always being rewritten into the .aux file after losses of synchronization.
Differences in the source codes of ANDI/RANDI concern especially the module foa.c, which had to be reprogrammed according to the different format structure of RADARSAT and ERS1. Further changes were made in randi.c - Scan(), al.c and in fra.c - especially fraGetNextFrame().
[return to top]RANDI Start and Command Line
The Program is started using the following command line format:
randi infile [-o outfile] [{+|-}f typelist [-s startpos] [-e endpos] [-i ID] [-v{on|off}] [-u] [-c] [-l level] [-a] The image above shows the file and directory structure in which the RANDI Software is stored. The whole Software consists of the RANDI program to process the raw data (located in randi/src/randi), interface functions to store this data into the DRD files (located in randi/lib/srcDrdlib) and tool programs to use the DRD files (randi/src/tools). The files printed in bold letters are important parts of the RANDI main program. A directory `bin' is needed in the same directory where the `randi' directory is located in order to store the executable programs. The rest is unimportant stuff: in directory randi/lib/srcHjwlib you find the file hjwlib.c, this is the source code for some little subroutines. In directory randi/obj are stored all object files created during the making of the executable programs. Randi/include contains hjwlib.h, which belongs to hjwlib.c. All of these files are not important for changes on the RANDI Software.
Summary Messages 1: Format level messages 2: Frame level messages 3: Lowest level messages Activates the "CareFree" mode, the default is CareFree mode program will read whatever raw data it gets without taking care how disturbed it is. This mode should only be used in case of emergencies! The processed data might be unreliable! format level messages reported default is CareFree of. Read only save raw data.
Summary of the RANDI Filestructure
[return to top]
RANDI Main Program
The RANDI main Program consists of the files randi.h, randi.c, al.c, foa.c and fra.c, further it uses functions of the modules stored in randi/src/srcDrdlib. The "Documentation for ANDI" gives a summary of the layered organization of the program. The include file randi.h contains constants, structures/unions[1] , global variables and all the function declarations for the RANDI program.
The main program of RANDI is represented by randi.c. When started, this program interprets the input in the command line, if the command line is incorrect it displays a help page and terminates, otherwise it reports what output files will be produced and what level of report the user will get. Afterwards the DRD library is opened - for all the opening, reading or writing actions concerning DRD files the program uses subroutines in randi/lib/srcDrdlib, so these subroutines are interface functions between the decoding program RANDI and the DRD library. Then the input file is opened, now the function Scan() - this function represents together with its subfunctions the core of randi.c - starts working. It calls the function alNextBlock() and gets a whole format back, afterwards the auxiliary data is calculated and in case something changed is written to the .aux file. The auxiliary data is usually given as an integer value with a certain number of bits, the real value has to be calculated by formulas given in Rev. F, page 17 - 34.
The spacecraft time is written when data changed or after the synchronization in the data was lost, so the user knows after a synchronization loss at which spacecraft time the valid data begins again. When there is replica present in the format (at the beginning of each 8th format) it will be written to the .rep file, then the echo data of the format is written to the .echo file, in case that there are fill bytes (zeros) they are stored in the .zero file. The number of replica and echo samples can be calculated as described in Rev. F, p. 36 (3.4.5.3.2 and 3.4.5.3.3). Many of the DRD interface functions are specialized to ERS 1, instead of using these, Scan() does more of the work itself. The processing of the auxiliary data became a very big part of Scan(), not complicated but long. Everything about it can be found in Rev. F, page 17-34.
For file operations the DRD interface functions are used, Scan() never uses low level file functions itself. For debugging purposes the variable bDrdDebug can be set to 1 in the main() program, then all the DRD interface functions will document what they're doing at the moment. After writing all data of a format, Scan() tries to read the next format, until the end of the input file or the halt point specified by the user is reached. The module al.c (access level) contains the function alNextBlock() - this function gets the next Format from foaGetNextFormat() and checks if Formats were lost - and access functions[2] used by Scan() to extract auxiliary data. The access function alGetAuxData() returns the values of the auxiliary data field and indicates changes since the last entry into the file by setting flags. The ephemeris data distributed over 55 formats, therefore the decoding is a little bit hairy, as the float chart shows: current word in the ephemeris array of 55 words. The function tries to find the synchronization, which consists of two succeeding words with special values. After this was found, the next 53 words represent ephemeris data and are stored. Only when afterwards again the synchronization pattern was recognized, the flag will be set to success. In case, the data has changed since the last time, it will be stored now. The core of foa.c (format access level) is the function foaGetNextFormat() The following image shows a float chart of this function.
FoaGetNextFormat reads the next format frame by frame (using fraGetNextFrame() ), but only if all the frames of a format could be read this format will be accepted as valid data. If a new format shall be read, the next first frame of a format (this is indicated in the frame header) is searched, usually it should be the next frame in the raw data. When found, the frames of this format are read continuously into g_myForm, the correctness of the frame and format number is checked during this action. The number of frames is not fixed for RADARSAT, so the end of a format is detected by the beginning of the next Format. When the first frame of a format is lost, the end of the format before and the beginning of the new one can't be detected and the two formats will be lost. The module fra.c (frame level) is responsible for reading the frames out of the raw data. This data is just a bitstream, so it usually won't match the byte borders in the memory directly after reading from the input file. Therefore it usually has to be bitshifted (fraShiftBuffer) before the program can make further use of it.
The most interesting function in fra.c is fraGetNextFrame(), it reads a frame, stores the values of the header and the descrambled application data field (this is scrambled by a pseudo random noise sequence) into the frame structure (*pFrame).
[return to top]Open questions
-what work is left to do on RANDI? Unfortunately, I didn't have the chance to process real RADARSAT data, so some problems occurred where I couldn't decide whether I didn't get an expected result because of an error in my program, in the simulated test data or in the manual:
-the frame error control field, which contains the CRC check word, can be used to detect transmission errors in the received frame. When I processed the checkword I didn't get the values stored in the test data, though the frames of the test data seemed to be undisturbed. The CRC check has to be done before unscrambling the frame. The corresponding function call is implemented as comment at the moment, the function fraCrcOk() itself is programmed. Read Rev. F, page 41 for further information.
-the Ephemeris data bothered me quite a bit. The synchronization word was stored as CCAA F0F0 in the test data, unlike written on Rev. F, p. 26. I also only got reasonable results when I didn't use two's complement for the integer values. There might be some corrections to do when real RADARSAT data will be processed. The part of the program responsible for reading the ephemeris data can be found in the module al.c, function alGetAuxData(). The calculation and output of the data is done in randi.c, function Scan().
-To make the use of ANAPULSE possible, I made RANDI write a mixing frequency shift of 5.3 Ghz (which is the same as the radar frequency, so the chirp diagram produced by ANAPULSE starts at 0 Hz) into the ".aux" file, this value has to be corrected in randi.c, WriteHardInfo().
[return to top]
How to modify the ANDI/RANDI software
Modifying ANDI, I often had to watch directly the raw data in order to verify the results the program calculated. To do this, the tool xv is very helpful. However, don't forget, that the raw data is a bitstream! So before viewing it you have to shift it with the bitoffset given by RANDI (there will be a message in the beginning, saying "First Sync found at file offset X, bitoffset Y").
To do so, the program file_shift (directory randi/src/tools) can be used. In order to start in any way before having an understanding of the whole ANDI program, I followed the bottom up concept, started changing fra.c, where I only concentrated on the parts important for the modification (fraGetNextFrame() ) and worked up through foa.c (because of bigger differences between ERS 1 and RADARSAT this part had to be reprogrammed), al.c (the access functions had to be reprogrammed) to randi.c itself, where the function Scan() was the only part to be changed. Unfortunately, I didn't have any real RADARSAT data, because the modifications were made before the launch of the satellite. So I used different files of simulated test data, which was not always satisfying, as described in the chapter "Open questions". The test data usually didn't contain real echo data, replica data was present, though. But the variable length of the formats, dependent on whether replica is present or not, was not simulated, to name only one of many weaknesses. Pretty helpful for debugging of RANDI is the flag bDrdDebug, if set to 1 you get many informations of what the interface functions do at the moment.
At a nice day the program suddenly and unexpectedly made it without errors through the whole 87 MB of my test data file. To check the error handling, I started injecting errors in the test data by disturbing synchronization patterns and observing how the program would handle it. Important to understand RANDI's error handling for the programmer is the knowledge of the module foa.c.
In the beginning I found it hard to understand the name of RANDI's variable definitions, here a short summary that might help:
Every function name begins with a prefix named after the module the function belongs to.
The prefixes of the variable names indicate the data type:
c for character
i for signed integer
u for unsigned integer
n for an integer counter
sz for zero terminated strings
b for a integer used as boolean
f for a floating point variable (lf = double)
A preceding p stands for a pointer to the variable.
A preceding l stands for a large version of the variable.
A preceding a stands for an array.
For example pliName is a pointer to a 32 bit signed integer.
The naming conventions are described in the "Documentation for ANDI".
[return to top]Trouble with RANDI
[return to top]Errors in the program
RANDI is a fairly large program and I'm a rather inexperienced C programmer. There might still be terrible bugs in the program.
One source for errors might be the module foa.c. It is responsible for the format reading. If there are errors, they will probably be found in the function foaGetNextFormat(). This function is entirely new programmed and therefor not long term proofed. I don't expect to many errors in fra.c, there were no big changes compared to the ERS 1 version. However, in case of errors concerning the values stored in the frame header, fraGetNextFrame() is a good place to look for trouble. To implement the CRC check also fra.c has to be modified (the function fraCrcOk() is programmed but not in use at the moment). Al.c contains the function alGetAuxData(), a tricky part (sea float chart above) was the ephemeris data, which is stored in the auxiliary data segment of 55 following formats. Error or not, is the question... In randi.c Scan() was changed, it is responsible for saving the echo, replica and auxiliary data into the DRD files after processing the values (like temperatures) out of the raw data. Especially the handling of the auxiliary data is fairly complex, there will occur nearly for sure some errors when real data is being processed.
[return to top]RANDI handling of disturbed/corrupted raw data
The module foa.c defines, how RANDI handles the flexible frame length of RADARSAT formats. If RANDI is not able to read all the frames of a format, it will loose the format. The end of a format is detected by the beginning of the next format, if the first frame of the next format cannot be detected, both formats will be lost. It is important to know, that the first frames of formats are marked in a special way, so RANDI will not accept any frame it finds first of a certain format as the beginning of this format, except it is marked as "first frame". With the switch -u in the command line set, RANDI will read unsafe frames, these are frames, where the following frame synchronization couldn't be found. In a case were just the first frame of a certain format was disturbed, RANDI will read the previous format when this option is set. Usually, it wouldn't read the last frame of the previous format because it cannot find the synchronization of the following frame, this would result in a loss of two formats. However, the default setting for RANDI is not to read unsafe frames. This might show, that The default settings of the program ensure a very secure handling of the raw data, this might result in the loss of one or two formats time by time that might not be much disturbed, but compared to much over 1000 formats in a usual raw data file this shouldn't be a big problem, and it gives a good guaranty for the results. The error handling of RANDI can sometimes be pretty confusing. It might be helpful to process the raw data multiple times using different levels of error messages. An example for RANDI output while processing a rather disturbed area of the raw data is shown underneath (error output level is default: 1).
...
REPORT: First Frame (27) of Format 193 found at Fileposition 3135
REPORT: Missed 2nd Frame (28) of Format 193, found
REPORT: Frame (28) Format 403, Fileoffset 3458
REPORT: Missed 1st Frame of Format 403, found
REPORT: Frame (28) Format 403, Fileoffset 3458
REPORT: First Frame (57) of Format 450 found at Fileposition 12825
REPORT: Missed 2nd Frame (58) of Format 450, found
REPORT: Frame (58) Format 688, Fileoffset 13148
REPORT: Missed 1st Frame of Format 688, found
REPORT: Frame (58) Format 688, Fileoffset 13148
REPORT: First Frame (87) of Format 963 found at Fileposition 22515
REPORT: Missed 2nd Frame (88) of Format 963, found
REPORT: Frame (88) Format 973, Fileoffset 22838
REPORT: Missed 1st Frame of Format 973, found
REPORT: Frame (88) Format 973, Fileoffset 22838
...
In the frame number in brackets represents the original value of the frame counter of the spacecraft. Remember, that you can get the value for the original satellite format counter by either calculating modulo 256 of the given values or extracting the last byte in any other way.
[return to top]DRD Interface functions
If you want to write further tool programs which make use of the DRD library, the DRD interface functions described in the manual "Documentation for ANDI" on the "Decoded Raw Data Access Library" pages can save a lot of time. The library <randi/include/drdapi.h> has to be included into the program and the libraries drdlib.a and hjwlib.a have to be linked to it. The compiler call is:
cc NameOfProgram randi/lib/drdlib.a randi/lib/hjwlib.a
The file randi/include/drdapi.h declares the functions of the DRD interface and the DRD output file structure:
typedef tagDRDFILE { FILE *file; char *pszFileName; uint bRead : 1; uint bStdOut : 1; uint bFilePosValid : 1; ulong luImageScanNo; ushort uNo; ulong luBlockLenght; long lnHeaderLength; char szType[15]; int iTypeMajorVer; int iTypeMinorVer; char szDate[20]; char *pszProgram; int iProgMajorVer; int iProgMinorVer; char *pszSatellite; char *pszFacility; char *szID; char *apszComments[]; int nCommentLines; } DRDFILE; The DRDFILE data type includes the whole header data and the file handle of a file of the DRD. It is read when the file is opened. The variables of the DRDFILE type should not be changed directly, there are DRD interface functions provided for this purpose.
| Variable | Description |
| file | File handle |
| pszFileName | Name of file (without path) |
| bRead | Flag is true if file is opened in read mode |
| bStdOut | Only in use for the report file. Flag is true if the |
| report file is opened for additional output to standard | |
| output. | |
| bFilePosValid | Indicates if the current file position is valid |
| luImageScanNo | Current image scan No to assure writing ascend Image |
| scan numbers. | |
| uNo | additional numbering, only used for writing calibration |
| pulse data | |
| luBlockLenght | current block length, used for writing of zero data |
| luHeaderLength | length of the header in bytes. Used to find the |
| beginning of the data section in a file | |
| szType | Name of the file type |
| iTypeMajorVer | Major version of the file type |
| iTypeMinorVer | Minor version of the file type |
| szDate | Date of creation |
| pszProgram | Program name of the program that generated the file |
| iProgMajorVer | Major version of the program above |
| iProgMinorVer | Minor version of the program above |
| pszSatellite | Name of the Satellite |
| pszFacility | Name of the facility |
| pszID | ID-string (used to identify files that belong together) |
| apszComments |
Array of strings, that contain the comment line. Eachline is one sting. The end of the array is marked by an NULL pointer
[return to top]Tool
programs The tool programs in randi/src/tools use the DRD files to calculate different results and store it in a form where these results can be graphically displayed by the program diagram. The tools are described in the "Documentation for ANDI". I corrected some errors in the tool programs dumpblock, anapulse and power and added also an autodetection of the bit quantization of the satellite to the tool sdevf. Therefore, it should be better to use the tools in randi/src/tools. I added another tool called rawlocate which reconstructs the location of the different raw data types out of the drd library files (spacecraft independent) and displays them graphically using the program dx. Different data types are shown in different colors. Rawlocate also calculates a histogram of how many bytes of each data type were in the raw data stream.
[return to top]The DX - Display Program
The dx tool is a program using the Xview library to display images that are stored using one byte colordepth. This program is used in the calibration/validation team to view SAR images. To show the images, 24 bit color is used, the user can choose between different display modes. These modes are: greyscale, color, random color, raw data and powerloss mode. Dx allows the user to adjust the linelength of the image, so different image formats can be viewed. Unfortunately, until now all these options had to be set using command line parameters, which made the program flexible, but meant that the user had to quit and restart the program with new parameters whenever he wanted to change something. Therefore my task was to change the program so that interactive adjustments by the user would be possible.
[return to top]Modifications
First of all I installed two sliders, these allow to stretch or upset the current colortable. Values for the sliders range from 0 to 255 (according to one byte colordepth of the image), pixels with values smaller than the low slider will be shown in the so called "LoColor", pixels with greater values than the high slider will be displayed in "HiColor". In between a colorramp is used. The program allows different modes, like greyscale, raw color mode (ramp from dark violet to red) or color mode (ramp from black to red, yellow, green, turquoise, dark blue, violet and white). If the high slider is moved to values smaller than the current setting of the low slider the colors will be inverted. The sliders are moved using the mouse pointer, the user can also select a slider and then use the keyboard to enter numbers. To give the user a better control of the current color table, I added a colorwedge that shows the color distribution from 0 to 255 (this range represents the possible values for pixels). Sometimes the length of the lines in the image is unknown, but can be adjusted using the trial and error method. Therefore a input box was added where the length can be entered using the keyboard or adjusted using up- down- keys. The program redraws immediately the image in the new format. The next step was, to allow the user to do a hardcopy of the current image. A little save menu allows choosing between color PostScript, greyscale PostScript and GIF-format, this should give compatibility to many computer systems. When saving is activated, the image is stored in three different temporary files, each for one of the RGB colors. These three files are converted to PGM-Format, then the last conversion step to the selected format can be done. The program creates names for the saved files that include a counter counting upwards during a dx session, so multiple files can be saved, also the appropriate file extension will be added. After saving, all the temporary files are removed. In the beginning, "LoColor" (see explanation of the sliders) was always black, "HiColor" always white. Now I added two menus, where the user can choose these colors out of the palette black, white, two different greys, red, blue, green and yellow. Using the corresponding command line parameter ("-lc" and "-hc") the three RGB values can directly be set. As an example, the user now can work in greyscale mode, adjust the high slider to 220 and get all pixels in the image with values greater than 220 in yellow.
I had some problems with the color in the pulldown menus, after the first usage the font in the menu would usually be set equal to the background color, the menu still worked, but all the choices were invisible. I guess, that the callback routines for pulling down the menus (I used internal callbacks of Xview) created this problem, so I finally decided to create a second window for some of the program's controls. In this window the default colortable is used and the menus work fine now. The sliders, the colorwedge and a quit button remained in the main window, all the controls that are not needed frequently (the color menus, another quit button, the saving menu, a menu for choosing the current display mode of the program and a message box, where outputs of dx are shown), can be found in this control panel window now.
[return to top]Program Internals
Dx first of all initializes different resources and creates the elements needed as user, like Pushbuttons, fields for input or sliders for adjustments. The drawing areas, called canvasses have to be created. For each element of the user interface, that allows interactive handling, "callback" resources have to be defined, these procedures handle the input of the user. E.g., the user changes the length of the image lines, then the corresponding callback resource has to redraw the image using the new size. When all these initializations are made, the program passes the control to the notifier. The notifier takes care, how user input has to be focused to the different callback functions. Now not each element of the user interface has to keep track of every event activated by the user, but each element receives only events the user has directed to it. A pushbutton handling subroutine
e.g. will only be called, when the pushbutton really was pressed by the user, and not any time the user presses the a mouse button. The notifier takes away a lot of filtering of all the event handling procedures of a program. The flow of a notifier controlled program is shown below:
The Motif-Toolkit
One of the problems of the calibration team was, that we used two different workstation types, a Sun Sparc Station and a DEC Workstation. Many of the programs running on the old Sun (especially a program to view satellite images) wouldn't run on the newer DEC, so the idea was, to learn something about the motif toolkit (which can be used on both machines) to be able to port some programs to the DEC. Unfortunately, because of problems with the installed Motif version we had to drop this project for the moment. However, I learned something about motif in this project, here a little summary: Motif was created by the Open Software Foundation, a non-profit consortium of some companies like HP and IBM. It is a set of guidelines that describe how a graphical user interface (gui) should look and feel. Important for a user interface is, that it should be consistent for all applications on a certain type of computers, it should be as simple as possible, but despite simplicity, it should not restrict functionality (advanced users should be able to handle the application in a professional way).
The motif specification is independent of how it is implemented, however, to guarantee a certain portability, the OSF chose to implement motif using the X-Windows system and the X Toolkit Intrinsics as platform for the application programmers interface. Motif can be used by applications written in C. The motif specification is broken down in two main parts:
-output model (describes how objects on the screen, like Pushbuttons or pulldown menus, should look like)
-input model (defines, how the user interacts with the objects on the screen)
Motif follows the concept of the notifier controlled program like described above in the chapter "dx - program internals". It provides different objects, one class is called widgets, which are independent from the application but can interact with it through prearranged links. There might be, for example, a widget consisting of a window and a pulldown menu, the application is only called when the user chose a certain option in the pulldown menu, all the management before is done by the widget, so buttons know, how to react when pressed and so on... . For the different options of the pulldown menu there are different links to functions in the application, called the callback resources. There are also so called manager widgets that are invisible to the user, there job is to control the layout of other widgets, so the application doesn't have to care what to do when a widget is moved or resized by the user, they also take care of objects called gadgets, that are comparable to widgets but can not interact with the user on their own like a widget, but need for this a manager widget. The following picture shows, how a certain application interacts with different layers of libraries to create a motif user interface.
The X Toolkit Intrinsic is used for creating and setting resources of widgets, the motif toolkit (Xm library) provides the widgets themselves. It might also be necessary for an application to use lower level functions like the Xlib (X Window System functions) (e.g. for graphical purposes), system calls to the operating system or functions of different libraries.
[return to top]Conclusion
of my summer internship Don't use vi!
Be a player!
I want to thank especially my "Supervisor Man" Jason Williams, who always understood my problems very fast (despite the language problems) and could give helpful advise how to proceed. His patience is unbelievable! I got a good impression in what house building is, too, might be helpful for my future.
I further want to thank Tom and Shari George for their hospitality that differed much from what I'm used in Germany (no big deal...), also for lending various household stuff, mountain bikes etc. I enjoyed Tom's flight trips very much! All the other people of the ASF helped to give me a great time, too, the working conditions are excellent in the ASF.
I had planned to do my "Praktikum" in a foreign country in order to improve language skills and get in contact with a different life style of people, let's skip the language, the latter was very interesting.
Thank you all for the great time!!!
The "thimble boy"
[return to top]Useful Literature
Jet Propulsion Laboratory, Interoffice Memorandum RADARSAT X-band ICD, Rev. F (Draft), 16 March 1995
Spar Aerospace Limited, RADARSAT In-Orbit Calibration
RADARSAT International, World Wide Products & Services, Price List
Curlander/McDonough, Synthetic Aperture Radar
Samuel W. Candless, Jr., Dr. Steven A. Mango, The Theory, Design and Application of Space Based Synthetic Aperture Radar
Hans-Joerg Wagner, Documentation for ANDI Dan Heller, Paula M. Ferguson, Motif Programming Manual, Volume Six A, B
[return to top]