Army Research Laboratory 

A Revised Design for the MMS-P: 

The MMS-P January 1998 Demo Design and 

Proposed Changes 

BY 

Edward Vidal Jr. 

Edward M. Measure 

Miguel A. Suriano 

Computational and Informational Sciences Directorate 

Battlefield Environment Division 

ARL-TR-1042 September 2000 

Approved for public release; distribution unlimited 

20000927 005 
* 

t 

NOTICES 

Disclaimers 

The findings in this report are not to be construed as an official Department of the 

Army position, unless so designated by other authorized documents. 

Citation of manufacturers’ or trade names does not constitute an official 

endorsement or approval of the use thereof. 
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

‘ublic reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, 

lathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this 

nllection of information, including suggestions for reducing the burden to Washington Headquarters Services, Directorate for information Operations and reports, 1215 Jefferson 

Iavis Highway, Suite 1204, Arlington, VA 22202-4302 and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188). Washington, DC 20503. 

1. AGENCY USE ONLY (Leave Blank) 

I 

REPORT DATE 3. REPORT TYPE AND DATES COVERED 

Lptember 2000 

1. TITLE AND SUBTITLE 5. FUNDING NUMBERS 

4 Revised Design for the MMS-P: The MMS-P January 1998 Demo Design and Proposed Changes 

i. AUTHOR(S) 

3dward Vidal Jr., Edward M. Measure, Miguel A. Suriano 

‘. PERFORMING ORGANIZATION NAME(S) AND ADDRESS 8. PERFORMING ORGANIZATION 

REPORT NUMBER 

U.S. Army Research Laboratory 

Computational and Information Sciences Directorate ARL-TR-1042 

ATTN: AMSRL-CI-EA 

White Sands Missile Range, NM 88002-5501 

3. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS 10. SPONSORlNGlMONlTORlNG 

AGENCY REPORT NUMBER 

U.S. Army Research Laboratory 

2800 Powder Mill Road ARL-TR-1042 

Adelphi, MD 20783-1145 

11. SUPPLEMENTARY NOTES 

12a. DlSTRlBUTlON/AVAlLABlLlN STATEMENT 17.b. DISTRIBUTION CODE 

Approved for public release distribution unlimited. 

A 

13. ABSTRACT (Maximum 200 words) 

Accurate artillery first round fire-for-effect requires correction for the effects of the atmosphere on the trajectory. Wind 

density, and speed of sound effects, if not properly compensated, produce very large errors. The traditional method fo; 

computing the corrections is based on measurement of the atmosphere using a balloon-borne radiosonde. 

The Meteorological Measuring Set Profiler will supplement or ieplace the balloon-borne radiosonde with remote sensiq 

techniques, and the single radiosonde profile through the atmosphere will be replaced by a meteorological model whicl 

provides a 4-dimensional(3 dimensions of space plus time) representation of the atmospheric state in the battle zone. These 

changes not only provide more timely meteorology, but also provide meteorology in the launch area, at apogee, and in the 

target area. The system design described here links major components by Ethernet and uses Java to interface wit1 

individual components and manage overall system functions. 

The Java-based system integration scheme proved its ability to integrate a diverse group of sensors operated by computer! 

using several different operating systems. 

14. SUBJECT TERMS 15. NUMBER OF PAGES 

57 

artillery meteorology, profiler, system design 

16. PRICE CODE 

17. SECURITY CLASSIFICATION 18. SECURITY CLASSIFICATION 19. SECURIN CLASSIFICATION 20. LIMITATION OF ABSTRACT 

OF THIS REPORT OF THIS PAGE OF ABSTRACT 

UNCLASSIFIED UNCLASSIFIED UNCLASSIFIED SAR 
Preface 

This report describes the design of a proof-of-concept profiler systems 

for measuring meteorological corrections for Army artillery. 

1 
Contents ’ 

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

Executive Summary .......................................................................................................................... 5 

1.0 Introduction .............................................................................................................................. 7 

1.2 background ........................................................................................................................... 7 

1.2 The MMS-Profiler Proof-of-Concept System ................................................................... 7 

1.3 Purpose/Objective.. ............................................................................................................. 8 

2.0 Three Versions of the MMS ................................................................................................... 9 

2.1 The Fielded MMS.. ............................................................................................................... 9 

2.2 The MMS-P as of January 1998 .......................................................................................... 9 

2.3 The MMS-I’ (Revised Version) ........................................................................................... 9 

3.0 MMS-P Sensors and Systems .............................................................................................. 11 

3.1 Design Concepts ................................................................................................................ 11 

3.2 Sensors and Subsystems ................................................................................................... 12 

3.3 Hardware Interconnection Design .................................................................................. 13 

4.0 Data Flow in the MMS .......................................................................................................... 15 

5.0 Data Flow in MMS-P98 ......................................................................................................... 17 

5.1 Surface Sensor .................................................................................................................... 18 

5.2 MARWIN Data Flow.. ....................................................................................................... 20 

5.3 Radiometer Data Flow in the MMS-98 ........................................................................... 21 

6.0 Connections and Data Flow in the MMS-I’ (RV) ............................................................ 23 

6.1 SMS and MARWIN Data Flow in the MMS-I’ (XV) ...................................................... 24 

6.2 Radiometer Data Flow in the MMS-P (XV). ................................................................... 26 

7.0 Combined LCU and CAAM/BFM Functions.. ................................................................ 27 

8.0 Remaining Issues ................................................................................................................... 29 

8.1 Connections and Interfaces.. ............................................................................................... 29 

8.2 Data Transfer from SEASPACE Satellite Sys tern ............................................................. 30 

9.0 Conclusions ............................................................................................................................. 31 

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

Acronyms .......................................................................................................................................... 35 

Appendices 

Appendix A. Clientunc ............................................................................................................ 37 

Appendix B. ServerLis t.java .................................................................................................... 43 

Distribution.. ..................................................................................................................................... 47 

3 
Figures 

1. MMS-I? hardware interconnection, January 1998 demonstration ...................................... 14 

2. MMS hardware connection diagram ..................................................................................... 15 

3. Connections of the eight-port boards in the MMS-P98 ....................................................... 17 

4. SMS data flow in MMS-P98 ..................................................................................................... 19 

5. MARWIN data flow in MMS-P98.. ......................................................................................... 20 

6. Radiometer data flow in the MMS-98 .................................................................................... 21 

7. MMS-P (RV) system connectivity ........................................................................................... 23 

8. SMS and MARWIN data flow into SC0 Unix computer .................................................... 24 

9. Data Flow from Marwin to SC0 Unix computer. ................................................................ 25 

lo. Radiometer data flow, proposed changes.. ........................................................................... 26 

11. System connectivity, unresolved issues.. ............................................................................... 29 

tY 

ir 

4 
Executive Summary 

General 

Accurate artillery first round fire-for-effect requires correction for the 

effects of the atmosphere on the trajectory. Wind, density, and speedof-sound effects (mediated by virtual temperature effects), if not 

properly compensated, produce very large errors. The traditional 

method for computing the corrections is based on measurement of the 

atmosphere using a balloon-borne rawindsonde. Unfortunately, 

rawindsonde launches are expensive and time consuming. Current 

systems can only track one balloon at a time; therefore, by necessity, 

balloon launches are widely spaced in time. The necessity of a 

hydrogen generator or a supply of helium adds logistical complexity. 

Finally, the rawindsonde can only make measurements along the 

trajectory of the balloon, which goes where the wind blows it. 

The Met Measuring Set Profiler (MMS-P) is intended to supplement 

the balloon-borne rawindsonde with remote sensing techniques. The 

single rawindsonde profile through the atmosphere will be replaced 

by a meteorological model product which provides a 4-dimensional 

(3 dimensions of space plus time) representation of the atmospheric 

state in the battle zone. These changes not only provide more timely 

meteorology but also provide meteorology in the launch area, at 

apogee, and in the target area. 

Development of a proof-of-concept system embodying extensive 

previous research was begun in FY 1997. Because the system was 

based on integrating several existing sensor systems with the current 

Met Measuring Set (MMS), and each component used a different 

operating system and proprietary software, the resulting system 

integration task presented many challenges. The adopted system 

concept linked major components by Ethernet and used JAVA to 

interface with individual components and manage overall system 

functions. 

In January of 1998, a full-scale demonstration of system and sensor 

connectivity and communication was conducted. The present report 

describes the system configuration at the time of the demonstration 

and discusses the lessons learned from that demonstration. A 

principal result of the demonstration was to prove the feasibility of 

integrating the hardware using the JAVA-based system concept and 

5 
6 

system integration software. It revealed, however, several 

opportunities for simplifying, streamlining, and otherwise improving 

the efficiency and increasing the capability of the system. 

Conclusions 

The JAVA-based system integration scheme proved its ability to 

integrate a diverse group of sensors operated by computers using 

several different operating systems. Opportunities for optimization 

remain. 

Recommendations 

With the basic soundness of the system demonstrated, future efforts 

should concentrate on improving the system speed, simplicity, and 

efficiency within the overall conceptual scheme. Decreasing the 

physical volume of the processing hardware should remain a priority. 
1.0 Introduction 

1.1 Background 

Accurate artillery first round fire-for-effect requires correction for the 

effects of the atmosphere on the trajectory. An artillery shell is 

subjected to drag forces during its flight that depend on wind, 

density, and virtual temperature. These effects, if not properly 

compensated, produce very large errors. The traditional method for 

computing the corrections is based on measurement of the 

atmosphere using a balloon-borne rawindsonde. The current U.S. 

Army system for providing this information is the Met Measuring Set 

(MMS) AN/TMQ-41. 

The MMS consists of a system for: 

l launching and tracking balloons, 

l gathering the resulting sounding data, and 

0 communicating it to the weapon systems. 

Unfortunately, this system has several disadvantages. The 

consumables required by rawindsonde launches are expensive and 

the operation is time consuming. Current systems can only track one 

balloon at a time; therefore, by necessity, launches are widely spaced 

in time. The balloons need a supply of lighter-than-air gas for lift, 

which requires a hydrogen generator or a supply of pressurized 

helium cylinders. These constitute a hazard and add logistical 

complexity. Finally, the rawindsonde can only make measurements 

along the trajectory of the balloon, which goes where the wind 

blows it. 

1.2 The MMS-Profiler Proof-of-Concept System 

The U.S. Army Research Laboratory (ARL), Computational 

Information Sciences Directorate (CISD), Battlefield Environment 

Division (BED) has designed and built a proof-of-concept system 

replacement for the MMS, which is called the MMS-Profiler (MMS-I’). 

While this design was conceived as a product improvement to the 

MMS, it incorporates far-reaching changes in design and capability. 

These stem from new methods for gathering, interpreting and 

analyzing data, especially remotely sensed data. [1,2,3] 
1.3 

The proof-of-concept system MMS-P has been in development for 

some time, starting with experiments in remote sensing technology 

that began in 1984 at the U.S. Army Atmospheric Sciences Laboratory 

(the predecessor of the current CISD, BED). The proof-of-concept 

evolved from isolated instruments to a fieldable collection of trailers 

until the technology was deemed ripe for design of an operational 

proof-of-concept system in early FY 1997. An initial tabletop 

demonstration of the integrated system was conducted in 

January 1998. 

The MMS-P proof-of-concept system is capable of producing a 

vertical profile of wind speed and direction, temperature, relative 

humidity, and atmospheric pressure from the surface to 20 km. The 

system includes sensors, programs for data fusion, and a meso-scale 

meteorological model. The sensor suite consists of a Semi-automatic 

Meteorological Station (SMS), wind radar, temperature, and moisture 

sensing radiometric profiler, facilities for launching and tracking 

rawindsondes, and a satellite receiver. Several computers, 

interconnected by Ethernet, manage data assimilation; data fusion; 

and communication with the tactical network via the Single Channel 

Ground and Airborne Radio System (SINCGARS). Another 

connected computer runs a meso-scale meteorological model, the 

Battlescale Forecast Model (BFM). The BFM assimilates the MMS-P 

data, Navy Operational Global Atmospheric Prediction System 

(NOGAPS) model gridded data from the Air Force Weather Agency 

(AFWA), upper air soundings and surface data to derive and provide 

met messages to field artillery fire units. 

Purpose/Objective 

The purpose of the present report is to document the design of the 

hardware and software that handles the MMS-I? data assimilation and 

communication. Suggestions for improving the design for faster 

execution are discussed. Means for reducing the, number and 

complexity of the hardware and software interfaces are considered. 

The design shown represents the system as of the January 1998 

demonstration. 

8 
2.0 Three Versions of the MMS 

’ L 

i . 

2.1 The Fielded MMS 

The MMS is currently fielded as a primarily a balloon-based system. 

Its sensors are the SMS and the MW12 MARWIN rawindsonde 

system. The SMS measures surface winds, temperature, and 

humidity while the rawindsonde measures balloon position, 

temperature, pressure, and humidity aloft. The rawindsonde data is 

communicated by radio to the MARWIN system and then to the 

Lightweight Computer Unit (LCU). The SMS data goes directly to the 

LCU where the data is combined to produce meteorological messages 

that are transmitted via the SINCGARS radio system. Data flow 

details are shown in section 4.0 of this report. 

2.2 The MMS-I? as of January 1998 

Although the MMS-P was conceived as a product improvement to the 

MMS, it represents a radical redesign incorporating the addition of 

many new sensors and greatly increased computer-processing power. 

The new sensors and systems of the MMS-P proof-of-concept system 

are discussed in detail in section 3.0 of this report. The primary 

purposes of the present report are to describe the basic features of the 

proof-of-concept system as of January 1998 (which will be referred to 

in this report as MMS-P98) and contrast them with some suggested 

design improvements. 

The MMS-P of the January 1998 experiment was designed to 

minimize changes to the original MMS. This was motivated by two 

situations: 

1. the need to interface with other existing systems (e.g., the 

SINCGARS) and 

2. the idea of building the system from more or less independent 

modules. 

2.3 The MMS-P (Revised Version) 

The design described above minimized the changes to the LCU 

software but incorporated some major inefficiencies, which are 

described in more detail in sections 5.0 and 6.0 of this report. 

9 
These inefficiencies resulted in extra hardware and inferior system 

performance. Consequently, a redesign of the system was 

undertaken. The resulting design reduces hardivare requirements 

and improves system performance. 

10 
3.0 MMS-P Sensors and Systems 

This section describes the MMS-P system, with emphasis on the 

common features of the 1998 and revised version (RV) systems. 

3.1 Design Concepts 

Development of a proof-of-concept system embodying extensive 

previous research was begun in FY 1997. The concept underlying the 

design was the integration of a suite of sensors and 

information-processing technologies to replace the balloon. The 

principal technical barrier that was confronted was the difficulty of 

integrating these diverse technologies, each with its own complex 

hardware and software base, running on computers under four 

different operating systems. The expense of rewriting all the software 

and rebuilding all the hardware to run on a common platform would 

have been enormous. In addition, most of the subsystems were 

commercial off-the-shelf systems, much of the underlying software 

was proprietary. The approach adopted was a novel adaptation of 

state-of-the-art techniques of software reusability, networking, and 

the JAVA programming language. [3,4] 

The MMS-P system concept links major components by Ethernet and 

uses JAVA to interface with individual components and manage 

overall system functions. The objective was the design of hardware 

and software that would permit data to captured from several sensors 

without redesign of the individual sensor subsystems. Because 

networking protocols run on virtually all kinds of systems, and 

because of the portability and multi-threading capabilities built into 

JAVA, the individual sensors can operate virtually independently 

while the data is being gathered and stored in a database. 

The top-down, object-oriented software design gives an 

unprecedented degree of modularity to the MMS-P’s data system, 

because virtually any computer-controlled sensor can be plugged in 

as another object in the sensor class. This design represents a 

paradigm that can be readily adapted to a wide variety of problems 

where diverse sensors or other devices need to be connected 

and cooperating. 

11 
3.2 Sensors and Subsystems 

The MMS-P makes use .of local instruments, a local meteorological 

model, information communicated from remote instruments, and 

information from large scale models. The soundings it produces are 

communicated by SINCGARS radio. 

The SMS, a component of the standard MMS, measures surface wind, 

temperature, pressure, and humidity. Its output is processed by the 

LCU computer and is used by the MARWIN as well as providing 

surface meteorology for the MMS-I’. 

The primary upper-air wind sensor is the 924 MHz, phased-array 

Doppler radar. The relative phases of the transmitting elements can 

be varied to transmit in each of five directions. The signal scattered 

from atmospheric refractive index discontinuities is Doppler shifted 

in proportion to the radial component of the velocity of the scattering 

components of the atmosphere and that Doppler shift is measured in 

a range-gated, heterodyne detection scheme. Vertical and horizontal 

winds are inferred from combinations of the radial velocities in the 

various directions (see, e.g., reference 3, p. 816). The range gating of 

the returns results in a vertical profile of the wind velocities from 

about 100 m above the surface to the height at which the radar runs 

out of signal-to-noise ratio, typically about 4 to 7 km above the 

surface. A dedicated radar computer processes the radar data. [3, p. 

8161 

The primary sensor of upper-air temperature, humidity, and liquid 

water is the microwave radiometer. The radiometer is a passive 

instrument that measures the natural microwave emissions of 

atmospheric oxygen, water vapor, and liquid water. Its retrievals are 

most accurate in the lowest 6 km of the atmosphere. 

The MARWIN is the rawindsonde system used by the MMS. 

The Seaspace satellite receiver system receives data for the polar 

orbiting meteorological satellites and can process the data to produce 

wind and temperature fields, as well as visual and infrared imagery. 

The SINCGARS radio is the tactical communication link for the MMS 

and the MMS-P. 
, 

The BFM gives the MMS-P the capability to produce nowcasts and 

forecasts of the meteorological conditions along the trajectory, in the 

target areas, or anywhere else within 500&m square. 

The DirecPC is a specialized satellite network system that permits 

global model data to be downloaded for use by the BFM. It is a 

receive-only system. 

3.3 Hardware Interconnection Design 

The backbone of the system is the local area network (LAN). There 

are five computers connected by the LAN: 

l one SEASPACE Sun SPARC 20, 

l three Pentium PCs, and 

l one 486 PC. 

A sixth computer, the Army LCU was not connected to the LAN 

during the January 1998 experiment. These six computers make use 

of four different operating systems: Solaris UNIX, Santa Cruz 

Operation (SCO) UNIX, Microsoft Windows NT, and Microsoft 

Windows 95. Listed below are these six computers, their processors, 

operating systems, and principal functions. The Computer Assisted 

Artillery Meteorology (CAAM)/BFM computer serves as a surrogate 

LCU, and only one of these is on the system at a time in the 

configurations discussed below. 

Computer Processor Operating Principal functions 

Sun SPARC 20 

Radar computer Pentium 

MI’S Main Pentium 

CAAM/BFM Pentium 

DirecPC 486 

system 

Solaris UNIX 

Windows NT 

Workstation 

Windows NT 

Server 

SC0 UNIX 

Windows 95 

Satellite data receiver and 

processor 

Radar control and data 

acquisition 

Main, data base, serial 

instrument controller 

Run BFM, create CAAM 

messages 

Receive data from IMETS and 

NOGAPS 

LCU Pentium SC0 UNIX Control MARWIN and 

SINCGARS 

.; 

.:. 

: . 

I.’ 

Note: 

MPS Mobile Profiler System 

13 
On the MPS Main (Windows NT Server) system, an eight-port 

module is used to ingest the data from the SMS, MARWIN, and the 

radiometer. Two ports are required for each sensor. On the LCU 

system, another eight-port module is used to ingest the data from the 

SMS, MARWIN, and to have access to a printer. This made for 10 

serial ports between the NT and the SC0 systems. This design 

allowed the data stream from the SMS and MARWIN to be captured 

in the NT system with a minimum of changes to the MMS software. 

Figure 1 shows the layout of systems in the January 1998 

demonstration. In the diagram, computers, instruments, and 

peripherals are represented by large rectangles. Lines ending in 

smaller, darker shaded rectangles attached to the computers represent 

the LAN, and lines ending in arrows represent serial connections. 

The zigzag lines represent radio communication via SINCGARS. The 

dark blue line shows data flow from the SMS to MPS Main while the 

green line shows it echoed to the LCU. Similarly, the sky blue line 

shows data flow from the MARWIN to the MPS Main and the pink 

line shows the MARWIN data being echoed to the LCU. 

Dashed area 

original MM S 

, 3,9,00 , L ___________________ -------- ----------------- -----: 

Figure 1. MMS-P hardware interconnection, January 1998 demonstration. 

Note that the LCU is not connected to the LAN in the January 1998 

configuration. 
4.0 Data Flow in the MMS 

Figure 2 shows the data flow in the MMS. Note that five serial 

connections are involved: 

l one with the SMS, 

. one with the printer, 

l three with the MARWIN. 

Figure 2. MMS 

hardware 

connection diagram. 

The connection shown from the Tactical Communications Interface 

Module (TCIM) to connect to the SINCGARS is a Small Computer 

System Interface (SCSI). One of the serial ports used is native to the 

LCU and the other four pass through the Digi 8, &serial port board. 

This figure will serve as a baseline for the discussion of the MMS-P98 

and MMS-P (RV) below. The Digi 8 boards and the software to 

control them are described in an ARL report. [7] 

r-4 LCU SERIAL using 

OS: SC0 UNIX TCIM 

I 

+ 

SNCGARS 

is 

RALXO 

SMS = SEMI-AUTOMATIC MET STATION 

MARWlN requires 3 serial ports 

1. S2 for IOsecdata 

2. S5 receives Surface Sensw readings. 

3. Sl communications with LCU. 

Met Messages 

SMS /de& yi 1 d or ldevIttya03 

MARWXV S 1 fdevltty2a 

MARWIN S2 /dev/ttyi 1 c or /dev/ttyaO:! 

MARWIN S5 /dev/ttyil b or /dev/ttyaOl 

PRINTER /dev/ttyi 1 a or /dev/ttyaOO 

The eight-port module attached to the LCU was added to the original 

MMS under a Value Engineering Change Proposal (VECP) and was 

used for communication with the MARWIN and the LCU printer. In 

addition to the output communication, s2 shown in figure 2 for the 

MARWIN, s5 is an input to the MARWIN, and the LCU also conducts 

a bi-directional communication with the MARWIN through one of its 

native serial ports. The fourth eight-port module serial port connects 

the LCU to a printer. 

15 
5.0 Data Flow in MMS-P98 

. 

In addition to system connectivity, figure 1 (section 3.0) shows the 

paths of data flow in the MMS-I’. The dotted line is drawn around 

the original MMS components. Comparison of figures 1 and 2 will 

show that the original MMS core looks almost unchanged. The major 

difference is that two data paths that go directly from instruments to 

the LCU in figure 2, go (figure 1) into the smart board of ME-main 

computer. Two corresponding data paths also go (figure 1) from the 

MIS-main smartboard to the LCU smartboard. 

The purpose of these changes was to make the original design of the 

MMS-P minimally impact the MMS software. Because the SMS and 

MARWIN rawindsonde observation (raob) data were needed by both 

the LCU and the MMS-I’, a design was adopted in which the output 

of the SMS and MARWIN were captured by MI’S Main via ports 3 

and 5 of the attached eight-port module. These signals were echoed 

to the LCU via ports 4 and 6 of the MI’S Main eight-port board and 

thence to the p3 and p4 ports of the smart board attached to the LCU. 

Figure 3 shows the connections between the eight port boards in 

more detail. 

Operator conh-01s Mawin 

data sent to LCU and back 

to printer. Met Message 

generated by Ma-win 

MPS 

Digi PC/Se 

8 Port Module 

DTE 25M 

(1 

7GRD 4-J 8 DCD 

20 DTR 

s2 

Corn 5 Ea. Corn Port 

. 

l 

* 

Corn 

Corn 

9 

10 

MPS 

’ WlN 

NT 4.0 

4 _ SERVER 

Idevlttyi lc pm data from Mawin 

f Corn 6 

/dev/tyyild Surface Sensor Corn I 

P4 4 Corn 4 

Raob Simulator 

/’ 

Surface Sensor Simulator 

Figure 3. Connections of the eight-port boards in the MMS-P98. 

17 
18 

This design produced minimal changes in the configuration of the 

original portion of the MMS but did so at a cost in efficiency. 

Software and system processing time were needed to process and 

echo the incoming signals, and delays were introduced. In addition, 

six ports were required to handle the signals that had formerly 

required only two. 

The sensors and peripherals are connected to the system by serial 

connections to the two eight-port smart board modules. Each smart 

board has an onboard buffer and controls eight serial ports. A 

detailed interconnection for the two eight-port modules is shown in 

figure 3. In the figure, the large rectangle in the center represents the 

eight-port module attached to the MPS main computer; the smaller 

rectangle at the lower left represents the same on the LCU (only four 

of the eight ports are shown). 

The MI’S main computer can run simulators for the SMS surface 

sensor and the MARWIN balloon system. When the system is run in 

that mode, the simulated MARWIN output is sent from COM 7 to 

COM 5 in place of the actual MARWIN s2 output. Similarly, 

simulated SMS output is sent from an MI’S native serial port to 

COM 3. The real or simulated MARWIN data coming in on COM 5 is 

sent out to the LCU via COM 6 (of the MI’S smart board) and p3 (of 

the corresponding LCU module). Similarly, SMS data gets to the LCU 

via COM 4 and p4. 

5.1 Surface Sensor 

Data flow from the SMS AN/TMQ-50 (surface sensor) and 

supporting software is diagrammed in figure 4. 
SMS in 

1 

SMS (Surface Sensor) Data Flow SMS out 

+ 

Corn 4 

Eight Port Module 

Digi PC/8e 

I T ! I 

w ( Digi Low level Driver ( 

SMS starts 

SurfSen Thread 

CommPort.DLL 

Requires JDK 1.1.3 

I I - 3/8/00 

Surtsenxtasr 

In a conventional MMS, SMS data would flow directly from the 

sensor to p4 of the LCU, but in the MMS-P98, the SMS data is first 

intercepted and stored in two forms on the MI’S computer. In the 

figure, the three rectangular boxes below the eight-port module 

rectangle represent the software interface with the MI’S main 

computer. From top to bottom, they are respectively, the Digi eightport board, low-level interface; the Windows NT (CommPort.dll) 

interface; and the JAVA (CommPortdass) interface. The ovals below 

represent JAVA objects. 

The SMS.class program instantiates the SurfSen.class program, which 

is the central communication node for the SMS sensor, receiving data 

from and sending data to the eight-port module, sending data via the 

toC.class to a C program that stores data to the sentxt file. It also 

receives location data, derived ultimately from the Global Positioning 

System (GE). 

Figure 4. SMS data flow in MMS-JTY8. 

19 
The combined data is time stamped and sent to be stored in the 

Microsoft Standard Query Language (MSSQL) database. The data 

sent back to the eight-port module goes to the LCU, and then to the 

MMS SC0 Unix system, where it is processed (wind direction 

converted from mills to degrees and wind speed converted to meters 

per second) and output on /dev/ttyiZb for input to the MARWIN. 

The LCU supplies data to the MARWIN processor and uses the data 

in an extrapolation model that in turn produces a nine line met 

message from surface observations. A UNIX pipe of the surface data 

is located in /usr/XUN/surfsin. 

. 

5.2 MARWIN Data Flow 

An analogous data flow diagram for the MARWIN data flow is given 

below in figure 5. Note the strong structural similarities in the 

software design, a feature of the object oriented modular design. 

The design (January 1998) calls for five serial ports on the LCU-the 

SMS and MARWIN data from MPS Main, the two-way channel Sl to 

Mark Marwin Data Flow 

s2 

1 

LCU 

t 

Corn 5 

Eight Port Module 

Digi PC/Se 

Corn 6 

the MARWIN, S5 to the MARWIN, and output to a serial printer. 

Digi Low level Driver I 

Marwin starts 

Raob Thread 

Requires JDK 1 .1.3 

Figure 5. MARWIN data flow in MMS-P98. 
-~-.- --.. 

5.3 Radiometer Data Flow in the MMS-98 

The final system directly affected by the proposed revisions is the 

radiometer. Figure 6 below shows the software outline for the 

radiometer in the 1998 configuration. The drastically different 

structure compared with figures 4 and 5 reflects the difficulties 

inherent in incorporating its software, which was written as a standalone disk operating system (DOS) program, into the modular 

architecture. 

r Radiometer 

WVR in 

Radiometer Data Flow Radiometer 

TP in 

COM9 

Eight Port Module 

Digi PC/Se 

A 

COMlO 

I Digi Low level Driver I 

p?iGzq 

COMMP0RT.C 

TP-WVREXE 

Keyboard 

DEFAULT.LOS 

DEFAULTSAV COMMSlNl 

DEFAULT.ERR WVR.CFG 

DEFAULT.LOG MTP.CFG 

COMMSLOG l/20/98 

Figure 6. Radiometer data flow in the h4MS-98. 

21 
. 

6.0 Connections and Data Flow in the MMS-P (RV) 

The design shown in figure 1 minimized the changes to the LCU 

software but incorporated two major inefficiencies-the delay and 

additional ports entailed by the shuffling of the data first into MI’S 

Main and then to the LCU. An even more important problem is 

connectivity with the LCU, which lacks the capability to connect to 

the LAN. 

The rationale for this design was that the MMS-P required the data 

provided by the SMS and this design minimized the changes to be 

made since the MMS-P was simply placed in the data flow of the SMS 

to the MMS. It was already planned that the LCU software would be 

transported to another SC0 UNIX computer with room for a LAN 

card. This was not implemented in the January 1998 configuration 

though, because we had not yet been able to solve the problem of 

integrating the TCIM (connecting the computer to the SINCGARS) on 

the computer. 

Since then, a more detailed understanding of the LCU code has 

revealed important potential improvements. The TCIM problem was 

solved, and the LCU code was transported to a more flexible 

computer. In addition, it was learned that the MARWIN and SMS 

data go to UNIX data pipes. Consequently, it is simple to put UNIX 

Tees in the pipes to send the data to one or more other locations. 

These facts make possible the following revised design, shown in 

figure 7 below. 

I 

SUN SPARC 20 

OS: UNWSOLARIS 

hL4lN PROCESSOR 

2W) MHZPENTIUM PC 

OS: NT 

2110 MHZ PENTIUM PC 

+ 

LCU 

OS: SC0 UNIX 

TUM 

SINCGARS 

Iw RADIO 

’ SMS = SEMI-AIROMATK MET STATlON L._____-- 

l ’ INTEGRATOR CONTROLLER DSP CARDS 

Now Return flow lhmugh LCU for IMETS data to 

re 

Figure 7. MhJS-P (RV) system connectivity. 

23 
The design includes a LAN connection to the LCU replacement 

(shown as the heavy black line) and now provides full connectivity of 

all MMS-P systems, which is essential for an automated system. The 

design in figure 7 also simplifies and speeds up the data transfer from 

the SMS and MARWIN. Four serial ports are eliminated, see specific 

sections devoted to the MARWIN and SMS below. 

The remaining design issue concerns how the data should be shared 

among the computers. Options considered included sockets, 

hypertext transfer protocol (HTTP), and the SAMBA file system. The 

SAMBA file system permits a UNIX system to share a disk drive with 

Windows systems. The SAMBA system, running on the LCU, was 

adopted because it provided a good mix of simplicity and flexibility. 

6.1 SMS and MARWIN Data Flow in the MMS-P (RV) 

The new system design used with SAMBA frees COM3 and COM4 on 

the MMS-P system. Figure 8 shows the data flow of the SMS and 

MARWIN data into the SC0 system where the processing takes place 

and the data is output to MARWIN s5 on /dev/ttyilb or 

/dev/ttyaOl. The lower half of figure 8 shows the software changes 

required. By comparing figures 4 and 5 with 8, the resulting design is 

cleaner and provides an improvement in the SMS data flow. 

I LCU Pentium 90 \ 

1 or CAAM 

~~ ..-.-..--.-.. 

cdurr/RUN/ ma&n 1 lusrlRUNlmyxmvin > ldcuhtyi I 

A__- ..-. - ..-.......--.. 

Ethernet --------------------------------c------------------------------ 

I ’ I 

----___-_____---____~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-~~~~~--- 

Qure 8. SMS and MARWIN data flow into SC0 UNIX computer. 

24 

. 
, 

I . 

. 

The hardware changes shown above require corresponding changes 

in the software. Because of the modularity of the system design, these 

changes are not great. For example, in figure 4, SMS data is received 

on COM3 by the MI’S main (NT) computer and retransmitted to the 

LCU via COM4. In the revised design, this data is received by MI’S 

Main via LAN from the LCU by means of a socket. 

This requires code changes on both computers. The required C code 

for the LCU (C1ientun.c) runs only 103 lines and is listed in 

appendix A. The corresponding code for MI’S Main is a modified 

version of the JAVA code used in the MMS-P98 to forward the SMS 

data to the LCU. It has been modified from sending a file to receiving 

it. This code, Server.JAVA, is only 59 lines, and is listed in 

appendix B. 

The situation with MARWIN data flow is very similar. The principal 

change on MPS Main is the replacement of the COM5 data flow with 

communication using a socket. The required software is very similar 

to that used for the SMS data. On the LCU side, the MARWIN data 

flow is shown in more detail below in figure 9. 

SMS 

(AN/TMQdO) 

Printer 

. 

MARWIN MW12 

- s2 

s5 Sl 

V t t I i”““““““““‘“““““““““” /dev/ttyi I d or /dev/ttya03 /dev/ttyila or /dev/ttyaOO /dev/ttyi Ic or ldevlttya02 dev /ttyil b or /dev/ttyaOl t-- 

/ LCU Pentium 90 

1 or CAAM 

_________--_-------------------- _____________-----

i%F :’ t Ethernet ClSSamba starts 

Sl7.ppt 

29Sep98 

.- 

Figure 9. Data Flow from MARWIN to SC0 UNIX computer. 

25 
The code required to send the data via LAN from the LCU to MI’S 

Main is very similar to that used for the SMS data. 

6.2 Radiometer Data Flow in the MMS-P (RV) 

In the MMS-I’98 design, the radiometer uses the eight-port module 

(Digi PC/8e) on the MI’S WIN NT 4.0 Server (figure 6). The 

radiometer is physically connected to COM9 and COMlO on the 

Digi PC/8e. The rationale for this design was that the radiometer 

software will runs on the MI’S WIN NT 4.0 Server. 

The RV design exploits the fact that this is not required. The 

radiometer can be physically connected elsewhere (figure 10) and 

communicate with the software on the MI’S WIN NT 4.0 over a pair of 

network sockets. Since it is being proposed that the MARWIN and 

surface sensor be connected physically to the LCU Pentium 90, the 

new design does the same for the radiometer. This move would 

eliminate the need for the Digi PC/8e on the MI’S Main computer. 

This would eliminate a large number of cables and improve the 

data flow. 

As was the case with SMS and MARWIN, only minor changes to the 

software are necessary to implement this change. Figure 10 shows the 

proposed changes to the radiometer data flow. 

Radiometer Radiometer Data Flow 

Radiometer 

Win TP in 

I 

Ethernet 

:ode in COMMS.LIB to connect both 

** Mod&i code to interface with CLIENT C 

*** New code for COMM Pan Socket Server, 

used to connect physical COMM ports to 

two sockets over the Ethernet network 

I*** Added exisfine code to store data into 

database. Only StoreDB.class is new 

igure 10. Radiometer data flow, proposed changes. 

26 
. 

7.0 Combined LCU and CAAM/BFM Functions 

In addition to the changes in port connections between figures 1 

and 7, the other major change is lumping together in figure 7 of the 

CAAM/BFM and LCU computers. This reflects the system redesign 

to combine the functions of the LCU and the CAAM/BFM computers 

in a single system. This was necessary because the LCU lacked the 

capability to connect to the LAN. An additional crucial benefit was 

the reduction in the total number of computers required by one. 

27 
8.0 Remaining Issues 

8.1 Connections and Interfaces 

The elimination of the eight-port module from the MI’S main 

computer leaves some unresolved issues, outlined below: 

b The sl connection between the MARWIN and the LCU is used to 

transfer the met messages to the LCU and for status information 

from the LCU to the MARWIN. The absence of this handshaking, 

which is not yet implemented on the LCU replacement, causes an 

alert on the MARWIN. 

0 The status of the LCU replacement’s interface to the TCIM is still 

undetermined. The TCIM is the interface to the SINCGARS 

(radio) that transmits to and receives messages from other fire 

control systems. 

b In the MMS, the s2 port of the eight-port module is used to print 

raob status and data during a flight. The status of this connection 

in the replacement LCU is not yet determined. 

The dotted lines in figure 11 indicate the locations of the unresolved 

connections. 

LAN 

DirecPC 

u LAN 

gi;ig 

I 

I 924 WI0 RASS I I 

RADIOMETER 

5 kW AMP 

SMS, , E.” r.. 

’ SMS = SEMI-AUTOMATIC MET STATION 

r-l- 

*’ INTEGRATOR CONTROLLER. DSP CARDS 

Note: Return flow through LCU for IMETS data to 

feed CAAMIBFM El 

214198 

I 

Figure 11. System connectivity, unresolved issues. 

J 

29 
30 

8.2 Data Transfer from SEASPACE Satellite System 

Currently, the SEASPACE is using a file transfer protocol (FTP) 

method of transferring its data to the MMS-I?. A method employing 

client/server sockets, like that used for radiometer, SMS, and 

MARWIN data is preferable for the SEASPACE also. 

. 
9.0 Conclusions 

The lessons learned from operation of the system in the January test 

and subsequent analysis, resulted in a new design presented in this 

report. The new design reduces the hardware and simplifies of 

software interfaces. With the new design, the processes will run 

faster and will not interfere with the operation in the MMS mode, as 

was the case in the original design. 

31 
References 

1. Cogan, J., E. M. Measure, E. Vidal, E. Creegan, B. Weber, and 

D. Wolfe, “A Mobile System for Near-Real Time Atmospheric 

Soundings,” In Proceedings of the Second Symposium on Integrated 

Observing Systems, American Meteor. Sot. Phoenix, AZ, pp. 57-59 

11-16 January, 1998. (UNCLASSIFIED) 

2. Cogan, J., E. M. Measure, and D. Wolfe, “Atmospheric Soundings in 

Near-Real Time from Combined Satellite and Ground-Based 

Remotely Sensed Data,” Journal of Oceanic and Atmospheric 

Technology, Vol14, pp 1127-1138, October 1997. (UNCLASSIFIED) 

3. Cogan, J., E. Measure, E. Vidal, G. Vaucher, E. Creegan, B. Weber, 

D. Wolfe, “A HMMWV Based System for Near Real-Time 

Atmospheric Soundings Using Combined Satellite and Ground-Based 

Remote Sensing,” In Proceedings of the 1997 Battlespace 

Atmospherics Conference, San Diego, CA, pp. 223-228,2-4 December 

1997. (UNCLASSIFIED) 

4. Hogg, D. C., M. T. Decker, F. 0. Guiraud, K. B. Earnshaw, D. A. 

Merritt, K. I’. Moran, W. B. Sweezy, R. G. Strauch, E. R. Westwater, 

and C. G. Little, “An Automatic Profiler of the Temperature, Wind 

and Humidity in the Troposphere.” Journal of Climate and Applied 

Meteorology, Vol. 22, May 1983, pp. 807-831. (UNCLASSIFIED) 

5. Measure, E. M., Young P. Yee, Teddy L. Barber and Dick R. Larson, 

“Number of Non-Redundant Frequencies for Ground-Based 

Microwave Radiometric Temperature Profiling.” Journal of 

Atmospheric and Oceanic Technology, 6, 5, pp. 846-850, October 

1989. (UNCLASSIFIED) 

6. Wolfe, D., B. Weber, D. Wuertz, D. Welsh, D. Merritt, S. King, R. Fritz, 

K. Moran, M. Simon, A. Simon, J. Cogan, D. Littell, and E. Measure, 

“An Overview of. the Mobile Profiler System: Preliminary Results 

from Field Tests during the Los Angeles Free-Radical Study,” Bulletin 

of the American Meteorological Society, Vol. 76, No. 4, pp. 523-534, 

April 1995. (UNCLASSIFIED) 

33 
7. Vidal, E., Jr., Miguel A. Suriano Jr., and Edward M. Measure, 

Meteorological Measuring Set-Profiler Eight-Port Module hterface 

Design, ARL-TR-1538, U.S. Army Research Laboratory, White Sands 

Missile Range, NM, July 2000. (UNCLASSIFIED) 

34 

, 

. 

. 
Acronyms 

AFWA 

ARL 

BED 

BFM 

CAAM/BFM 

CISD 

DOS 

FTP 

GPS 

HTTP 

LAN 

LCU 

MMS 

MMS-I’ (RV) 

MMS-IJ 

MMS-I’98 

MI’S 

MSSQL 

NOGAPS 

raob 

SC0 

SCSI 

Air Force Weather Agency 

Army Research Laboratory 

Battlefield Environment Division 

Battlescale Forecast Model 

Computer Assisted Artillery Meteorology/ 

Battlescale Forecast Model 

Computational Information Sciences Directorate 

Disc Operating System 

File Transfer Protocol 

Global Positioning System 

Hypertext Transfer Protocol 

local area network 

Army Lightweight Computer Unit 

Met Measuring Set 

MMS Profiler (proof-of-concept system, revised 

version) 

MMS Profiler (proof-of-concept system) 

MMS Profiler (proof-of-concept system, version used 

in January 1998 test) 

Mobile Profiler System 

Microsoft Standard Query Language 

Navy Operational Global Atmospheric Prediction 

System 

rawindsonde observation 

Santa Cruz Operation 

Small Computer System Interface 

35 
SINCGARS Single Channel Ground and Airborne Radio System 

SMS Semi-automatic Meteorological Station 

TCIM Tactical Communications Interface Module 

VECP Value Engineering Change Proposal 

. 

36 

. 
Appendix A 

Clientumc 

37 
#include <sys/types.h> 

#include <sys/socket.h> 

#include <netinet/in.h> 

#include <netdb.h> 

#include <stdio.h> 

char DATA[lOOO]; 

/*#define DATA “sending data”*/ 

readmessg() 

I 

FILE *pt2; 

int i; 

char inputch; 

i=O; 

pt2=fopen(“3230681.met”,“r”); 

while(fscanf(pt2,“%c”,&inputch) != EOF) 

1 

DATA[i]=inputch; 

/*printf(“%c”,DATA[i]);*/ 

i++; 

1 

/*printf(“\ni=%d\n”,i);*/ 

i++; 

DATA[i]=O; 

fclose(pt2); 

I 

/* This program creates a socket */ 

main(argc, argv) 

int argc; 

char *argv[]; 

I 

int sdata; 

char *adddata; 

int sock; 

struct sockaddrjn server; 

struct hostent *hp, *gethostbyname(); 

char buf [ 10241; 

int rval; 

readmessgo; 

39 
40 

/* Create Socket */ 

sock = socket ( AF-INET, SOCK-STREAM, 0); 

if ( sock == -1) 

1 

perror( “opening stream socket” ); 

exit( 1); 

1 

/* Connect socket using name specified by command line */ 

server.sin-family = AFJNET; 

hp = gethostbyname( argv[l] ); 

printf(“hostname = %s\n”, hp->h-name); 

printf(“host-address-type = %d\n”, hp->h-addrtype); 

printf(“hJength = %d\n”, hp->h-length); 

printf(“host-address = %d\n”, hp->h-addr); 

pr-inet(hp->h-addr-list, hp->h-length); 

/* gethostbyname returns a structure including the network address of the 

specified host */ 

if ( (hp == (struct hostent *) 0 )) 

1 

fprintf( stderr, “%s: unknown host\n”, argv[l] ); 

exit(2); 

1 

memcpy( (char *) &server.sin-addr, (char *) hp->h-addr, hp->h-length ); 

server.sin-port = htons( atoi( argv[2] )); 

if ( connect( sock, (struct sockaddr *) &server, sizeof server ) == -1) 

1 

perror( “connecting stream socket”); 

exit(l); 

1 

adddata= &DATA; 

sdata=sizeof DATA; 

/* printf(“%x %d\n”,adddata,sdata);*/ 

if ( write( sock, adddata, sdata) == -1 ) 

perror( “writing on stream socket” ); 

if ( read( sock, buf, sizeof buf ) == -1) 

perror( “reading stream socket” ); 

printf(“%s\n”, buf); 
close( sock ); 

exit(O); 

I 

pr-inet(listptr, length) 

char Yistptr; 

int length; 

I 

struct in-addr *ptr; 

while ( (ptr = (struct in-addr “) *listptr++) != NULL) 

printf(“\nInternet address: %s\n\n”, inet-ntoa(*ptr)); 

c 

41 
. 

Appendix B 

ServerList.java 

43 
I y 

i - 

/* 

# $Header: 

\\\\EAGLE053\\default\\RCS\\K\\java\\src\\socket\\ServerList.java,v 1.3 

1998/02/03 19:42:52 administrator Exp administrator $ 

*/ 

import java.net.*; 

import java.io.*; 

import java.lang.“; 

public class ServerList 

static RandomAccessFile in; 

public ServerList(int port) throws java.io.IOException 

{ 

ServerSocket ss=new ServerSocket(port,l); 

System.out.println(“started”); 

/” . 

System.out.println(“Accepting connections on local machine ” + 

ss.getInetAddress().toString() + ” on local port ” 

+ ss.getLocalPort() + “.“); 

*/ 

Socket consock; 

InputStream sockinp; 

byte b[]=new byte[1024]; 

conSock=ss.accept(); 

sockinp=conSock.getInputStream(); 

int bread; 

/* 

System.out.println(“Connected to remote machine at ” + 

conSock.getInetAddress().toString() + 

” on remote port ” + conSock.getPort() + 

” using local port ” + conSock.getLocalPort() + “.“); 

*/ 

while(sockinp.available() > 0 ) 

1 

System.out.print((char)sockinp.read()); 

in.close(); 

I 

45 
public static void main(String a[]) throws java.io.IOException 

1 

if(a.length < 2) 

{ 

System.out.println(“Usage: ServerList <port> <filename>“); 

return; 

1 

in=new RandomAccessFile(a[l],“r”); 

ServerList ser=new ServerList(Integer.parseInt(a[O])); 

1 

46 

c 

L 
Distribution 

’ J 

NASA MARSHALL SPACE FLT CTR 

ATMOSPHERIC SCIENCES DIV 

E501 

ATTN DR FICHTL 

HUNTSVILLE AL 35802 

NASA SPACE FLT CTR 

ATMOSPHERIC SCIENCES DIV 

CODE ED 411 

HUNTSVILLE AL 35812 

US ARMY MISSILE CMND 

AMSMI RD AC AD 

ATTN DR PETERSON 

REDSTONE ARSENAL AL 35898-5242 

US ARMY MISSILE CMND 

AMSMI RD AS SS 

ATTN MR H F ANDERSON 

REDSTONE ARSENAL AL 35898-5253 

US ARMY MISSILE CMND 

AMSMI RD AS SS 

ATTN MR B WILLIAMS 

REDSTONE ARSENAL AL 35898-5253 

US ARMY MISSILE CMND 

AMSMI RD DE SE 

ATTN MR GORDON LILL JR 

REDSTONE ARSENAL AL 35898-5245 

US ARMY MISSILE CMND 

REDSTONE SC1 INFO CTR 

AMSMI RD CS R DOC 

REDSTONE ARSENAL AL 35898-5241 

US ARMY MISSILE CMND 

AMSMI 

REDSTONE ARSENAL AL 35898-5253 

PACIFIC MISSILE TEST CTR 

GEOPHYSICS DIV 

ATTN CODE 3250 

POINT MUGU CA 93042-5000 

ATMOSPHERIC PROPAGATION BRANCH 

SPAWARSYSCEN SAN DIEGO D858 

49170 PROPAGATION PATH 

SAN DIEGO CA 92152-7385 

METEOROLOGIST IN CHARGE 

KWAJALEIN MISSILE RANGE 

PO BOX 67 

APO SAN FRANCISCO CA 96555 

47 
48 

NCAR LIBRARY SERIALS 

NATL CTR FOR ATMOS RSCH 

PO BOX 3000 

BOULDER CO 80307-3000 

HEADQUARTERS DEPT OF ARMY 

DAM1 PO1 

ATTN LEE PAGE 

WASHINGTON DC 20310-1067 

MIL ASST FOR ENV SC1 OFC 

OF THE UNDERSEC OF DEFNS 

FOR RSCH & ENGR R&AT E LS 

PENTAGON ROOM 3D129 

WASHINGTON DC 20301-3080 

DEAN RMD 

ATTN DR GOMEZ 

WASHINGTON DC 20314 

US ARMY INFANTRY 

ATSH CD CS OR 

ATTN DR E DUTOIT 

FT BENNING GA 30905-5090 

HQ AFWA/DNX 

106 PEACEKEEPER DR STE 2N3 

OFFUTT AFB NE 68113-4039 

PHILLIPS LABORATORY 

PL LYE 

ATTN MR CHISHOLM 

HANSCOM AFB MA 01731-5000 

PHILLIPS LABORATORY 

PL LYP 3 

HANSCOM AFB MA 01731-5000 

AFRL/VSBL 

29 RANDOLPH RD 

HANSCOM AFB MA 01731 

ARL CHEMICAL BIOLOGY 

NUC EFFECTS DIV 

AMSRL SL CO 

APG MD 21010-5423 

US ARMY MATERIEL SYST 

ANALYSIS ACTIVITY 

AMSXY 

APG MD 21005-5071 

ARMY RESEARCH LABORATORY 

AMSRL D 

2800 POWDER MILL ROAD 

ADELPHI MD 20783-1145 
ARMY RESEARCH LABORATORY 

AMSRL OF’ CI SD TL 

2800 POWDER MILL ROAD 

ADELPHI MD 20783-1145 

ARMY RESEARCH LABORATORY 

AMSRL CI LL 

ADELPHI MD 20703-1197 

ARMY RESEARCH LABORATORY 

AMSRL SS SH 

ATTN DR SZTANKAY 

2800 POWDER MILL ROAD 

ADELPHI MD 20783-1145 

ARMY RESEARCH LABORATORY 

AMSRL CI 

ATTN J GANTT 

2800 POWDER MILL ROAD 

ADELPHI MD 20783-1197 

ARMY RESEARCH LABORATORY 

AMSRL 

2800 POWDER MILL ROAD 

ADELPHI MD 20783-1145 

NATIONAL SECURITY AGCY W21 

ATTN DR LONGBOTHUM 

9800 SAVAGE ROAD 

FT GEORGE G MEADE MD 20755-6000 

US ARMY RSRC OFC 

ATTN AMXRO GS DR BACH 

PO BOX 12211 

RTP NC 27009 

DR JERRY DAVIS 

NCSU 

PO BOX 8208 

RALEIGH NC 27650-8208 

US ARMY CECRL 

CECRL GP 

ATTN DR DETSCH 

HANOVER NH 03755-1290 

US ARMY ARDEC 

SMCAR IMI I BLDG 59 

DOVER NJ 07806-5000 

ARMY DUGWAY PROVING GRD 

STEDP MT DA L 3 

DUGWAY UT 84022-5000 

ARMY DUGWAY PROVING GRD 

STEDP MT M 

ATTN MR BOWERS 

DUGWAY UT 84022-5000 

49 
DEPT OF THE AIR FORCE 

OL A 2D WEATHER SQUAD MAC 

HOLLOMAN AFB NM 88330-5000 

PL WE 

KIRTLAND AFB NM 87118-6008 

USAF ROME LAB TECH 

CORRIDOR W STE 262 RL SUL 

26 ELECTR PKWY BLD 106 

GRIFFISS AFB NY 13441-4514 

AFMC DOW 

WRIGHT PATTERSON AFB OH 45433-5000 

US ARMY FIELD ARTILLERY SCHOOL 

ATSF TSM TA 

FT SILL OK 73503-5600 

US ARMY FOREIGN SC1 TECH CTR 

CM 

220 7TH STREET NE 

CHARLOTTESVILLE VA 22448-5000 

NAVAL SURFACE WEAPONS CTR 

CODE G63 

DAHLGREN VA 22448-5000 

US ARMY OEC 

CSTE EFS 

PARK CENTER IV 

4501 FORD AVE 

ALEXANDRIA VA 22302-1458 

US ARMY CORPS OF ENGRS 

ENGR TOPOGRAPHICS LAB 

ETL GS LB 

FT BELVOIR VA 22060 

US ARMY TOP0 ENGR CTR 

CETEC ZC 1 

FT BELVOIR VA 22060-5546 

SC1 AND TECHNOLOGY 

101 RESEARCH DRIVE 

HAMPTON VA 23666-1340 

US ARMY NUCLEAR CML AGCY 

MONA ZB BLDG 2073 

SPRINGFIELD VA 22150-3198 

USATRADOC 

ATCD FA 

FT MONROE VA 23651-5170 

ATRC WSS R 

WSMR NM 88002-5502 

1 
ARMY RESEARCH LABORATORY 

AMSRL CI E 

COMP & INFO SC1 DIR 

WSMR NM 88002-5501 

DTIC 

Y 8725 JOHN J KINGMAN RD 

STE 0944 

FT BELVOIR VA 22060-6218 

I US ARMY MISSILE CMND 

AMSMI 

REDSTONE ARSENAL AL 35898-5243 

US ARMY DUGWAY PROVING GRD 

STEDP3 

DUGWAY UT 84022-5000 

USTRADOC 

ATCD FA 

FT MONROE VA 23651-5170 

WSMR TECH LIBRARY BR 

STEWS IM IT 

WSMR NM 88002 

US ARMY RESEARCH LAB 

AMSRL D DR D SMITH 

2800 POWDER MILL RD 

ADELPHI MD 20783-1197 

US ARMY CECOM 

INFORMATION & INTELLIGENCE 

WARFARE DIRECTORATE 

ATTN AMSEL RD IW II’ 

FORT MONMOUTH NJ 07703-5211 

JAMES COGAN BRANCH CHIEF 

ARMY RESEARCH LAB 

AMSRL IS EA 

WSMR NM 88002-5501 

ARMY RESEARCH LAB 

AMSRL IS EA 

ALFRED GUTIERREZ 

WSMR NM 88002-5501 

ARMY RESEARCH LAB 

AMSRL IS EA 

EDWARD VIDAL JR 

WSMR NM 88002-5501 

ARMY RESEARCH LAB 

AMSRL IS EA 

EDWARD MEASURE 

WSMR NM 88002-5501 

15 

7 

51 
ARMY RESEARCH LAB 

AMSRL IS EA 

DAVID QUINTIS 

WSMR NM 88002-5501 

ARMY RESEARCH LAB 

AMSRL IS EA 

GAIL VAUCHER 

WSMR NM 88002-5501 

Record copy 

TOTAL 

52 

1 

85