A Low-Cost, Real-Time Network for Radiological Monitoring Around Nuclear Facilities

A low-cost, real-time radiological sensor network for emergency response has been developed and deployed at the Lawrence Livermore National Laboratory (LLNL). The Real-Time Radiological Area Monitoring (RTRAM) network is comprised of 16 Geiger-Mueller (GM) sensors positioned on the site perimeter to continuously monitor radiological conditions as part of LLNL’s comprehensive environment/safety/health protection program. The RTRAM network sensor locations coincide with wind sector directions to provide thorough coverage of the one square mile site. These low-power sensors transmit measurement data back to a central command center (CCC) computer through the LLNL telecommunications infrastructure. Alarm conditions are identified by comparing current data to predetermined threshold parameters and are validated by comparison with plausible dispersion modeling scenarios and prevailing meteorological conditions. Emergency response personnel are notified of alarm conditions by automatic radioand computerbased notifications. A secure intranet provides emergency response personnel with current condition assessment data that enable them to direct field response efforts remotely. This system provides a low-cost real-time radiation monitoring solution that is easily converted to incorporate both a hard-wired interior perimeter with strategically positioned wireless secondary and tertiary concentric remote locations. These wireless stations would be configured with solar voltaic panels that provide current to recharge batteries and power the sensors and radio transceivers. These platforms would supply data transmission at a range of up to 95 km from a single transceiver location. As necessary, using radio transceivers in repeater mode can extend the transmission range. The RTRAM network as it is presently configured at LLNL has proven to be a reliable system since initial deployment in August 2001 and maintains stability during inclement weather conditions. With the proposed reconfiguration to a combined hard-wired and wireless network, which incorporates a robust server and modeling software, the system would be a durable and economical radiological monitoring system for nuclear power plants around the world.


I. INTRODUCTION
In order to optimize a real-time radiological network's early warning capability, several design challenges for a sensor network must be met: • It must be robust (withstanding severe ambient environmental conditions); • It must be sensitive to all types of ambient radiation at the sensorcontaminant interface for direct measurements (range sensitivity within the mean free path of the radiation type for this direct measurement, i.e., alpha, beta, gamma); • It must possess the aspects of reliability and be reconfigurable for communications based upon deployment constraints (i.e., cellular or radio frequency based communication throughout it's expected deployment life-cycle); • It must be able to provide notification to a remote location through an automated response mechanism; • It must be able to provide continuous service without interruption of either power or communication; • It must be able to operate independently of other network services; • It must provide adequate information for the desired result; • It must be able to interface with data from disparate systems (such as meteorological instrument data).
When this system was envisioned as a continuous radiation field monitor, the initial intent was to provide the service of presenting the data to any number of remote users as requested.In order to attain this objective, we chose to use a distributed computing environment as a mode of data presentation which could be segregated as required.This environment is termed globally as the "web" for it's implied connectivity to data links but more appropriately segregated by user permissions.The user is either an "external user" or an "internal user".This meant retaining the ability to selectively deliver data to particular users.For example, end users do not need to maintain the same vigilant oversight of the systems daily health as system management personnel and consequently this information if it were available to the end user would not serve any useful purpose for them.The end user is only concerned with the system's performance and availability.With this in mind, clearly there may be occasions when an independent service is interrupted.An example of this is a condition that may arise as a "script running a piece of code to maintain a deliverable portion of data that is not presently being used yet does not affect the user at that instant".In this respect, the user is unaware that the system is not performing at 100% efficiency because the service that has been interrupted is not affecting the user at that moment.
For clarity we will refer to any independent data structure as a web link or "link" in this discourse and make specific reference as required to a central command center (CCC) as the distributed computing resource for the web data whether delivered to an "external audience" (unsecured-internet) or and "internal audience" (secure-intranet) as needed.

A.
Challenges of Real-Time Monitoring Selection of the proper monitoring equipment depends on the radioactive material's physical state, (i.e., gaseous or particulate) [1].Collection methodologies may be either passive or active and provide either a quantitative or qualitative result.Two examples of passive quantitative sensors are thermoluminescent dosimeters and pressurized ion chambers which are used to measure radiation dose.
Active sampling devices such as air samplers, have filters made from specific material that enhance the collection of either gaseous or particulate samples.Examples of gaseous collection media are carbon filters for the collection of radioiodine and silica gel for the collection of Tritium.These devices are also quantitative measurement sensors.Analogous to the volume of air breathed, an air sample measured for air activity per unit volume sampled represents the integrated air concentration for the sampling period.Active air sampling of this type is beneficial in exposure determinations.
Air particulate mass loading of the filter media usually occurs over a 1 week period after which the filter is removed from the field for analysis.This media is useless for gaseous radioactive material producing gamma radiation directly or by neutron induced secondary reactions.This is one example where the radiation type or physical state determines the sensor technology used to collect a sample for either quantitative or qualitative determination.Standard laboratory chemistry techniques are used to determine the type and quantity of radioactive material collected by filter media and several different analysis techniques may be required to gather all of the desired information.The process may be quite lengthy from placement of the collection media until receipt of the analytical results.
Further challenges based on radiation sensor types, (i.e., active or passive) and real-time data analysis are presented not only by power restrictions for field sensors but also by communication restrictions.LLNL maintains strict security requirements due to its national security mission.
Real-time identification of non-background radiation is a challenge in many respects.For example, in order to obtain isotopic identification in real-time, the monitoring equipment must be much more complicated which imposes further network design constraints.Additionally, other factors that impose requirements on real-time sensor designs are radiation type, elemental physical state, and physical decay half-lives.

B. Technology
The LLNL design goal was to detect all radiation types, be robust under environmental conditions, and be economical to operate.Priority was given to a network design utilizing components from commercial available technology.Gas filled ionization counter technology provides a means of detection for all radiation types, in any elemental physical state (i.e., gaseous, liquid, or particulate).Geiger-Mueller (GM) counters, which were introduced in 1928 [ are still considered the simplest radiation sensor to operate.GM counters provide the necessary detection properties for this application and have the benefit of reliability and sensitivity in low-radiation fields encountered in the environment following dispersion of low activity sources.Inherent difficulties exist in detecting alpha radiation produced by transuranic radioactive decay.The presence of natural occurring decay products [3] can mask regions of interest for the detection of low-level radiations from Plutonium-239 and Americium-241.However, by monitoring the ambient background environment continuously in real-time using GM counters, elevated count rates from any source are easily measured.The benefits of a qualitative response with this sensor technology override its limitations (that do not exist in other advanced devices).A thorough treatment of available technology may be found in [2].

C. Network Topology
Figure 1 -RTRAM sensor distribution roughly coinciding with the 16 compass sector directions from a centralized position.
The RTRAM sensor network illustrated in Figure 1, was distributed into 16 monitoring locations for two reasons.The first being division of the monitoring area by 16 direction sectors as is done for dispersion modeling and the second being the computer circuitry required for the station inputs (i.e., the counter boards each having 8 analog inputs such that two boards are required to attain 16 station inputs).This static reference grid is presented for an orientation perspective.The modeling section will re-address this important aspect of the sensor grid origin reference as discussed later in this paper.

II. CENTRAL COMMAND CENTER
The power and data processing for the RTRAM sensor network is maintained by the central command center (CCC) and it's computer host.The hard-wired configuration enables the distribution of power and data communication to be centralized in a location that permits direct access to the CCC computer and power circuitry by emergency response and system administrative personnel.This centralization of the console permits emergency response personnel to have local access to manage the emergency and be independent of network services and for system administration personnel for performance related needs.
An example where this may be necessary is a natural disaster such as an earth quake that disrupts network communications for the "hard-wired" network which may not be a predominant concern for a wireless network.The CCC resides in a facility that maintains back-up power by generator in addition to the local uninterruptible power supply (UPS) that is capable of providing 30 minutes of power to maintain both the distributed RTRAM network and the CCC computer.It should be noted that this is based on the LLNL 16-station "hardwired" network.

A.
Network Power and Signal Distribution Each of the 16 remote sites is connected independently to the CCC by circuits consisting of two unshielded twisted pairs of copper wire provided by the LLNL site infrastructure.The positive and negative applied voltage, signal, and reference ground are maintained by the CCC circuit for each remote sensor.The CCC circuitry maintains V a at ±15 volts direct current (vdc) on one pair while the signal and reference ground are maintained via the other pair.The signal pin of the sensor is held at +4.7 vdc until ionization occurs in the gas volume.Once ionization occurs in the gas, V s drops below zero.Each occurrence of this drop in potential indicates an ionization event.Two National Instruments (NI) PCI-6602 circuit boards were installed in the CCC computer to interface with the LabVIEW™ data acquisition program and count the ionization events.Since the LLNL communication infrastructure is well established site-wide, sensors may be located at any facility on the site.This allows the flexibility to relocate or add sensors to the network.So for those remote locations where the telecommunication infrastructure is restricted, the wireless configuration option becomes the obvious choice.This predisposes the network configuration to be a hybrid combination of hard wired and wireless configurations to meet the needs of NPP monitoring.

RTRAM Sensors
The RTRAM sensors deployed are pancake tube designs by LND Inc. that are mounted to the circuit board designs of AWARE Electronics Inc.The AWARE sensor circuit contains the components necessary to supply an applied voltage (V a ) to power the sensor and provide an output signal voltage (V s ) maintained at positive voltage potential for the CCC.The sensor configuration uses a 1.5 to 2.0 mg/cm 2 Mica thin window to allow charged particles, e.g., alpha (a) and beta (b), to enter the gas volume and begin an ionization event.

C.
Charge Recovery Each ionization event that occurs in the sensitive gas volume creates electrons and cations.The heavier cations migrate to the chamber wall at a much slower rate than the self-propagation of electron avalanches (i.e., Townsend), which are collected by the anode.The Geiger discharge results in a build-up of cations that surround the anode wire of the sensor and prevent further charge collection [4].A halogen quench gas is used to accelerate the sensor recovery with about 100 ms dead time adequate for low-level counting.

D.
Hardware Design The output of the RTRAM sensor facilitates connection over long transmission lines.Even though some of these lines are over 3 km long (due to indirect circuit pathways) the low power consumption of the sensor minimizes the voltage drop.The sensor has an open collector output that pulls the output to the negative supply when ionization in the sensitive volume occurs.There is a weak pull-up resistor to restore the output to the positive rail.With the output signal swinging between both rails, there is a lot of noise margin for long transmission lines.
The output signals of all of the sensors run through interface circuits to the NI PCI-6602 multichannel counter board installed in the CCC computer.The interface circuit is a 4.7 V zener diode to ground and a 1K ohm resistor to +15 volts.The diode clamps the positive signal to +4.7 V and clamps the negative pulses to approximately -0.7 volts.The 1K ohm resistor speeds up the pulse rise time so that closely spaced pulses are detected better and reduces the effects of noise on the slowly rising signal.The counter board that we used has Schmitttrigger inputs to avoid retriggering the counter as the detector pulse rises.During the prototype phase of the project we used a counter board that did not have Schmitt-trigger inputs, and we had to use an external Schmitt-trigger input buffer to avoid getting multiple counts due to the noise on the rising edge of the detector pulse.Testing with a digitizing oscilloscope showed that the combination of the above interface and the Schmitt-trigger inputs produces good noise immunity and a single count for each detection pulse.

A.
LabVIEW' Data Acquisition Software A LabVIEW' program is used to monitor the RTRAM sensor signal input, process and save the data locally, and send it to a UNIX file server.The LabVIEW™ program's Data Acquisition State Machine idles until the interval timer trips and then goes through the following states: Alarm Monitor The Alarm Indicator Management Loop runs continuously, scanning the "Alarm Global" variable which contains the parameter information for the alarm conditions.The "Alarm Global" variable contains the alarm parameter information for each of the channels being monitored by the system.The system allows alarm categories to be set for different responder action on the basis of alarm level.Upon detection of an alarm condition for any channel, the Alarm Contact Notification function is activated and sends out alpha pages for each channel that is alarming to all the selected officials associated with each alarm category.LabVIEW™ also sends electronic mail notification following the paging notice.Notices include alarm level, count rate, and the time to reach the threshold parameter dose at the present count rate.
The Alarm Indicator also activates an audio alarm on the CCC computer while the background color of the chart display for the alarming sensor is changed from a black to yellow background.The numerical value representing the number of hours that is required to reach a threshold dose at the present rate is boldly written in red text in the center of the display over the yellow background.

C. Setup Panel
The setup panel is the user interface for setting all program parameters and is accessed through a function on the system user control panel.For security purposes this panel has password protection in order to maintain system integrity.The setup panel allows the alarm test function to be initiated and operate independently of the normal operation.Details of the Alarm Test function are discussed below.

A.
Alarm Algorithm The alarm function is used for notification that action levels have been reached.The alarm algorithm is triggered by the LabVIEW™ code running on the RTRAM CCC where it is displayed locally.Scripts running on the Unix platforms also provide the same information which is displayed on the web page "Action Level Status" display.
Action levels are specified in terms of the number of hours (denoted by T S ) to reach a point source dose threshold limit (D L , millirem).This threshold is based on a sensor calibration using Cs-137 gamma reference energy of 662 kilo electron Volts (keV).Alarm response is determined for each sensor (S), based on whether the present count rate in counts/minute (cpm) of a short test period ( † x test , cpm) exceeds a reference or background value (B, cpm).T S is calculated by where In normal operation at LLNL, † x test is the average of the most recent three measurements, and B is either the average of the previous 30 measurements, or a fixed value of 30 cpm, whichever is smaller.The averaging of a small test set filters out randomly occurring transient (single measurement) spikes that could trigger a false alarm.The nature of dispersion eliminates the likelihood of singularities and is dependent on meteorological conditions and the duration of a plume passage event.† T S is recalculated every time a new measurement is acquired, separately for each sensor.Specifying action levels in terms of hours until a dose threshold is reached provides first responders with a gauge of the level of urgency from which to manage the incident as conditions change.

B. Alarm Test Function
The alarm test function provides a wellness check to ensure operational readiness.RTRAM network administrators perform periodic tests of the alarm notification process by selection of the "Alarm Test Function" located on the password secured set-up panel.As the alarm test program loads, a sensor selection menu that contains independent alarm level selector settings is displayed.The administrator may then select any number of network sensors and the test level to be conducted.The test results of actual pseudo-alarm condition values is sent through the radio paging and email text messaging system.An example of the message is shown below: The message contains the following information: • Action Level

A. Socket Communications
The RTRAM system uses sockets to communicate between the CCC computer and the UNIX file server.The listener process on the UNIX file server opens sockets for reading, while the CCC computer attaches to those sockets for writing.The CCC computer opens a new socket connection each time it has data to be sent.This improves reliability over a persistent connection, because this decouples the operations of the CCC computer and the listener.If the CCC computer is unable to open a socket (e.g.network problems, power outages, etc.), the data is buffered by LabVIEW™, dynamically allocating space as needed, and sent along with current data the next time the CCC computer is able to make a connection.Scheduled UNIX file server down-time, has shown no loss of data for periods of up to 3 days (69,120 data records at the 1 per minute rate of data acquisition for 16 locations).LabVIEW™ maintains local copies of the data as an insurance policy in the event of a catastrophic failure of the UNIX file server resulting in significant down-time.An example of this feature is shown in Figure 3.

B.
Data Packets Each data packet is transmitted in ASCII format, and contains the location identifier, a time stamp, and the sensor readings.Data is currently stored to flat files on the UNIX file system for rapid access to current data, and to a MySQL " database which provides greater flexibility for reporting and data management.

C. Listener Health & System Reliability
The RTRAM Listener resides on the UNIX file server and receives files from the CCC computer.This script is configured to be started any time the UNIX host is restarted.This ensures that if the host goes down, whether intentionally or not, the listener will be available as soon as the host is able to support it.Additionally, a listener health program runs hourly to ensure that the listener is still active.If the listener is not active, the program attempts to restart the listener, and an email is sent to system administrators indicating whether or not the listener was successfully started.Should these measures fail, yet another monitoring process is run from a separate host which will notify administrators when either RTRAM or the UNIX file server is unavailable.

D.
Monitoring of Conditions In addition to the alarm sequences mentioned above, the UNIX file server also provides alarms to users and system administrators.A system operational check is done by the listener to ensure data is being received.If no data is received by the CCC computer, LabVIEW™ sends a zero in the string for that sensor and the listener responds by sending a page to network administrators identifying the down sensor.

A. Overview
The RTRAM is a secure intranet site and serves as the primary interface for system users, emergency response personnel, and network administrators.The RTRAM computer displays provide both real-time and historical data for consequence analysis and modeling.
Dispersion modeling relies on source term information and other meteorological parameters to drive the modeling functions and produce an estimate of the exposure, deposition, and the extent of a radiological emergency.Sensor driven modeling is now being added as a resource for use in dispersion modeling codes.

B.
Intranet Interface A graphical display as previously shown as an aerial perspective line drawing in Figure 1, is used to visualize the relative position of the sensor system, provide hotlinks to sensor data pages, and correlate any plotted dispersion information.Each sensor location depicted on the site map is linked to specific information for that sensor.Presently this includes a close-up map, current sensor status and readings, current wind conditions, as well as links to available plots for that sensor.

A. LabVIEW™ Front Panel
The front panel data provides the real-time information directly to the EOC personnel.This is the most immediate form of the data.Following a few seconds of processing time, the same data is made available to all users through the web (as previously mentioned, we make no distinction regarding the type of distribution in this discussion).
As the data is processed by the LabVIEW™ code, each sensor data string is archived into their respective files identified by location, (i.e., Sensor-1, … Sensor-16).The data is simultaneously sent to the UNIX server where it is processed by R' making the necessary calculations for displaying the data in graphical format and ensuring readiness for interactive session availability via the web.
The front panel as termed by LabVIEW™ is essentially a screen console with graphical user interfaces (gui's) to access pre-programmed functions such as "Mute Alarm" (locally audible for console users), "Stop Paging", (discontinues the radio paging notification as the event is managed by personnel), and display information pertinent to the system users such as display scale adjustment button, operational status indicator, network information indicator, and parameter access buttons to change initial configuration settings.

FILE FORMAT
Sensor ID, Year-Month-Day 24-hr Time, CPM, mR/Hr, Interval SENSOR

A. Perl
Perl is the open source programming language used for general RTRAM software development.Perl is a powerful programming language that is particularly useful at unifying programs and processes.Perl has a very active user community that contributes language extensions back into the public domain.Perl was used to develop the listener, monitoring scripts, and intranet.Perl was also used to provide interfaces to R, MySQL " , and UNIX system utilities.

B. R Computer Language [5]
R is another flexible and powerful open-source programming language specialized for data analysis and graphics.R is available for all of the computing platforms used in the project.The intranet file server runs Sun Microsystems' hardware with the Solaris' operating system.Ad hoc data analysis takes place on Apple" computers using the Mac OS X operating system.R is also available for Linux and Windows‚ operating systems.R has object-oriented capabilities, making it very easy to use any customized plotting or analysis functions that are developed.

C.
MySQL " Although plain text files are convenient and easy to use, they are not conducive to storing "meta-data" information, such as information that might explain unusual measurements.For this reason, data is also stored in a relational database system.MySQL " , another open-source software package, was selected because it has a relatively low administrative overhead.

XI. DATA ANALYSIS AND GRAPHICS
We developed data analysis and graphical software routines using R to meet the following needs: • Prompt notification of unusually high activity levels • Convenient routine review of recent activity levels • Ad hoc review of activity levels (current, recent, or distant past) • Examination of trends at different time scales (15 minute, hourly, or daily averages) • Comparison of locations with each other • Prompt detection of problems (interruptions in data collection, erroneous data) As activity levels are measured, they are time-stamped; the times are always reported using an 8 hour offset from coordinated universal time (UTC) which correspond to (Pacific Standard Time).This eliminates any need to adjust for changes to and from daylight savings time during data collection and makes it directly compatible with LLNL meteorological data format.However, it is more convenient to display data using current local time.We felt this would be especially important during an unusual incident or emergency, so that individuals responding to the incident would not have to mentally translate times as they viewed graphics.R was selected also because its date and time functions correctly handled this issue.
The software design for graphics and data analysis is modular.Modules fall into three basic categories: (1) data input, (2) data selection, and (3) data review.Data input consists of functions that retrieve data from storage.R scripts run nightly to read all new data acquired since the previous night, and store it in R's internal format.Daily, hourly, and 15-minute averages are calculated at this time and stored along with the per-minute data.The data input functions may also be run manually at any time to examine selected data, without interfering with the regular daily data collection.Data selection consists of functions that let the user select which data to review by location and date range.Data review consists of functions to graph data in various ways, and check for special conditions such as unusually high activity levels or lapses in data collection.
Many of the data review functions are placed in scripts that are run at regular intervals, so that problems do not remain undetected.These scripts email summary reports to RTRAM staff.The script that monitors for action levels runs continuously.Special entries have been placed in the computer's startup scripts so that the monitoring script is automatically started whenever the computer is re-booted.The monitoring script is automatically checked hourly, and if it is not running it is restarted automatically.Some of the R scripts that run at regular intervals deliver plots to the intranet file server where users may view them.These include plots of the last four hours of measurements at every location, updated every five minutes; cumulative estimated dose updated daily; and daily averages for the last 90 days, updated daily.

X. EMERGENCY RESPONSE PLOT
This page web page link allows emergency responders to get a quick estimate of the 15-minute downwind plume that would be associated with a dispersion of radioactive material.The plume plot is calculated using average wind speed, average direction, and the average standard deviation of the wind direction, during the previous 15 minute sample interval from the LLNL meteorological tower.By default, this page assumes a static condition with a release point corresponding to the lab center, but for an actual consequence assessment, emergency responders enter the location of the release or an off-site location and the script plots a plume as appropriate.The Emergency Response Plot shown in Figure 4 represents a "plume-sensor" interaction display example of this capability.It illustrates a source term of "off-site" origin with a plume passing through several sensor sites.The plume is represented by a centerline of average wind direction ± a width parameter of the average directional standard deviation for the measurement period.The plume sector has a radial equivalent distance equal to the product of the average wind speed and sample period, plotted in km units.This is used as a leading edge plotted as a sector arc to determine sensor contact time.Color is used for plume definition in the program and not reproduced in this article.* (Note: This plot is dynamic and not rewritable following it's creation on 3-4-04 at 11:15 (PST).This plot was archived for documentation and copied for this article.This auto generation process adds a layer of security to the data stream which prohibits tampering.

XII. REAL-TIME DATA DRIVEN MODELING
Air dispersion modeling provides the most immediate assessment of a effect of a radiological release, but it is only an estimate based on sometimes inadequate data and can only serve as first response tool in the warning process for "down-winders".The RTRAM network incorporates realtime data driven meteorology with the radiological monitoring data to validate modeling output during changing conditions.Using a 15-minute time averaged plume dampens the effects of localized turbulence caused by either the surface terrain or wind turbulence that contributing to the fluctuations in wind direction.Spatial separation is a key component in determining the long range transport.As well as averaging for plume meander driven by the horizontal turbulence flux.Examples of this are found in urban areas where building wake effects will drive the local fluctuations in direction.
Transposing the "triggered sensors" of relevant sensor reference coordinates via global positioning system to local maps provide a Graphical Information System (GIS) mapping reference tool to assist the modeler.Although having the a prior knowledge of a source term release point may provide a dispersion modeler with enough information to make a rough consequence assessment, the model output is only as good as the meteorology input used.Therefore, having the ability to monitor the radiation field in conjunction with the present meteorological conditions will provide more accurate real-time modeling assessments.

A.
Portable sensors Low-power portable sensors with robust characteristics for extreme environmental conditions and communication via secure radio frequency (RF) or cellular phone would be of significant value.Although there have been many advances recently in portable sensor technology, many have concentrated efforts in the properties of the unit and not included vital communication system components such as Global Positioning Systems, (GPS) and integrated smart communication systems.

B. Communication reliability
In certain areas it may be more feasible to use one type of technology over the other.One example of the tradeoff is the transmission distance and power consumption versus cost.With RF technology the line of sight transmission increases the overall communication distance and the cost basis is basically an initial equipment costs and some installation time.With the cellular option, area coverage could become the limiting factor as well as interference and holes in the coverage area.Figure 6   In this application we chose to use MHz broad band spread spectrum radio transceivers.These RF units provide not only a range of over 95 km with direct line of sight, there are proprietary algorithms used to restrict the air traffic to known coded transceivers which precludes inadvertent interruption of transmission and lost data packets.

C. Ethernet Bridge / Serial Device Connectivity
The Ethernet bridge radio utilizes current Internet Protocol (IP) data transmission such that no modifications are required for IP ready devices.Serial conversion is necessary to enable standard serial devices to be used with this IP transmission protocol.This method know as "serial tunneling" encapsulates the serial data in an IP wrapper which may then be sent via the bridge radio.

XI. CONCLUSION
There are several difficulties in quickly identifying a potential radiological incident.The ability to identify airborne radioactive material from a stand-off position and mitigate a threat to human health requires timely and accurate assessment.We have shown our ability to install and maintain a simple and reliable sensor network that extends over a 1 square mile area (1.61 km 2 ) that has an immediate incident response mechanism when used to support data driven modeling can only serve to increase the probability of saving lives and minimize the effects of accidental exposure due to inaccurate modeling or untimely notification for "down-winders".
We have pursued the bench-test development of improved low-power systems which would add value to the present network by utilizing the same low-cost RTRAM sensor technology with inexpensive meteorological instruments capable of withstanding harsh environments.This pre-operational design package uses a low-power single board computer with integrated circuitry making the measurement, buffering data, and then making periodic data transmission to reduce the power consumption.Power conservation greatly enhances system reliability and performance and outweighs any reduced accuracy due to sampling frequency which is statistically insignificant.

A. Prototype Micro-Computer and Remote Sensor Platform
The prototype design uses an LP 3500 Fox [8] low-power single-board computer with the RTRAM sensor and a Met One 034 A cup anemometer and wind direction sensor (Model A has now been updated to Model B).The MetOne instruments are with their robust design are able to operate at temperatures of -30° to +70° C and wind speeds of up to 269 km/h.

B. Sample Frequency
In order to conserve power and optimize the data acquisition, four sampling periods are made each minute at roughly 15 second intervals.The data is then buffered and transmitted following the acquisition of a radio link.The basic process flow chart is depicted in Figure 7.

Modularity
In certain cases it may prove to be advantageous to utilize both types of transmission technology which certainly is easily experimentally determined.The obvious for the prototype design of the remote low-power system choice was to create an interchangeable or modular data transmission capability.This meant to be able to select between RF and Cellular based upon the driving need with no significant design modifications only the transmission termination point being that of an RF transceiver or GSM cellular telephone.
We anticipate the interactive connectivity of these simplified sensor networks to be used to activate more sophisticated sampling equipment capable of isotopic identification or active air sample interrogation as our work progresses.

D. Remote Low-Power Platform bench-test results
These preliminary test results shown in Figure 8 were created under laboratory conditions and have delivered the expected performance results that was sought in the design concept.Further development and experimentation with the design criteria should prove favorable in the near term.The operational cost should also prove to be minimal in comparison to the initial capital equipment and installation costs.
k and D cf are unit conversion factors; † k = 1000 mR millirem , and † D cf = 0.187 mR hr cpm

Figure 2 .
Figure 2.. LabVIEW™ front panel showing the 16 remote sensor displays on the CCC computer console.

Figure 3 .
Figure 3.This is an excerpt of an archive data string set representing the time frame of the data for Sensor 1. *Note: Boldface type string is the data captured in the console screen shot of Figure 2.

Figure 4 .Figure 5 .
Figure 4. Emergency Response Plot depicting the spread of a radioactive plume driven by the current meteorological conditions.Using the RTRAM meteorology archive retrieval tool we generated the following table of meteorology data used to generate Figure4onMarch 4, 2004.* depicts a typical Global Standard for Mobiles (GSM) cellular coverage area[7]  for Armenia.

Figure 6 .
Figure 6.GSM Cellular Coverage Area of Armenia.

Figure 7 .
Figure 7. Flow chart of the Low-Power Remote Sensor Platform Logic