The map background consists of a 500-kilometer circle whose origin is given
by the decimal latitude and longitude specified in the file cities.txt. The file states.txt contains the decimal latitude and longitude coordinates of the US states; it is a modified version of the file created and kindly provided to us by Mark
Mitchell, Lead Forecaster in the NWS at the Kansas City/Pleasant Hill, Missouri Office.
As examples of the files containing the city identifiers and locations, we provide two sample files, pacities.txt
that we use in the Penn State installation,
and kscities.txt that we use in the Lawrence,
KS installation. These city files also contain
the names and locations, in decimal latitude and longitude, of any cities
of interest in the surrounding area. These locations
can be found on the Web; some sample sites (current as of July 1998) listing
US cities that also include the three-letter station identifiers are:
Sites that give the
locations outside the US, in particular Canada, include:
http://www.realestate3d.com/gps/world-latlong.htm
If the code is run in Live mode, then the program first establishes connection
to the Experimenter A/D.
Next, the program calculates the four offset levels based on as many as
100 samples from each analog channel (2-NSoff, 3-EWoff, 4-E1off, 5-E2off);
the number of samples actually used will decrease somewhat if there is
lightning activity in the area. These offsets are used to subtract
from the four offset analog signals to restore their bipolar character,
with values within +2500 mV. Because the offsets may drift,
these are recalculated every 6 hours; if the Archiving option (arch
= 1) is chosen in param.txt, then the offset values are stored (for
possible troubleshooting use later) on the hard disk, in file MMDDYY.off,
which is stored in the complete path path$ given in param.txt,
where MM is the month, DD is the date and YY is the year.
If the code is run in Archive mode, then the file param.txt supplies
the file name (ffile$) and path (path$) of the data
of interest, MMDDYY.log, together with the starting hour (starthr)
and ending hour (endhr) for the loop. At any time in Live
mode, a single loop of that day's activity, up to the current time, can
be displayed via hitting a 5 on the keyboard and then supplying a starting
hour (starthr). Live data collection is suspended until this
loop is run.
In either Live or Archive mode, the code defines the timer values (in seconds
since midnight) that are used to keep track of the age of the plotted lightning
activity. The parameter oldtime, usually 30 minutes and set
in param.txt, determines the maximum duration in which a pixel denoting
the location of lightning activity remains colored--black if fewer than
rstp strokes have occurred within oldtime in that bearing
(rstp is set in param.txt and is often as low as 3), yellow
for intervals up to oldtime/2, and then red for intervals between
oldtime/2 and oldtime. When the data used to estimate
these locations are older than oldtime, they are removed from the
bearing-indexed stack; the values in this stack are sorted and used to
calculate average signal magnitudes, as described below. Also, the
screen refreshes every thirty minutes to clean up the display.
In Live mode, the program next enters a loop that constantly queries the
Experimenter A/D to see if a valid signal has been placed on the
four analog channels. A valid signal is indicated if a digital level
of 1 (Pulse High) replaces the normal value of 0 (Pulse Low). If
a 0 is detected, then the program first checks to see if any time-dependent
operation must be performed before beginning the valid signal loop
again; these operations include refreshing the screen, updating the screen
clock, determining whether to turn the attenuator
on or off, or deleting old negative return data from the stack. If
a 1 is detected, then the four analog channels are sampled and the appropriate
offsets are subtracted to produce bipolar values between -2500 mV and +2500
mV that are used for stroke identification and, if a negative return stroke
occurs, calculation of the estimated distance from the map center to the
location of the lightning activity.
If in Archive mode, then a line of data is input from the MMDDYY.log file.
Because the four channel values were conveniently stored in bipolar form,
they are ready to use in the next step below. Any time-dependent
operation that must be performed is checked in this part of the code too.
In either mode, the stroke type is determined using the following rules:
1) The stroke polarity is negative if e1 > 0, and the polarity is
positive if e1 < 0.
The type of stroke
(NR, Negative Return; PR, Positive Return;
NI, Negative Intracloud; PI, Positive
Intracloud) is indicated in the upper left of the screen by an appropriate
cartoon that is visible for a second or so. When the cartoon is erased,
then it is replaced with the corresponding two-letter stroke code.
If the stroke is not of type NR or if it is of type NR but its magnetic
signal magnitude B < minsig ~ 100 mV, then the code performs
no distance-related calculations with it. Instead it branches to
the Screen Update portion of the flowchart.
In Live mode, if the stroke is of type NR and if the beep option has been
activated in param.txt via setting the switch ibeep = 1,
then a brief tone is sounded by the PC speaker.
If the stroke is of type NR with B > minsig mV, then
standard trigonometric relations are used to estimate the bearing and magnitude
of the magnetic signal from the values of NS and EW. To adjust for
errors in the alignment of the antenna with respect to the east/west and
north/south planes, the user-supplied value (in param.txt) of degoff
is added to the bearing. The code then determines whether this new
stroke has occurred within 1 second and within +dupdeg <
2 degrees of an earlier NR. This check must be performed because
the software can obtain several samples per second from the Experimenter;
it is thus possible that several strokes composing a single lightning flash
will be detected. The stroke having the peak magnitude is generally
viewed as providing the best measure of the flash strength and so is
the one that the code needs to provide the best estimate of the average
signal magnitude. Unfortunately, the peak signal is not
always the first in the series composing a flash, but our experience has
shown that it usually occurs within about a second of the first one.
We have also found that any additional strokes from the same flash will
generally be seen to occur within two degrees or so of the initial one;
this variation in degrees is set in param.txt by the variable dupdeg.
If the most recent stroke is found to be weaker than an earlier NR in the
series, then the latest signal is ignored and the code next performs the
Screen Update. In contrast, if the most recent stroke is stronger
than the previously detected NR in the series, then the new signal replaces
that previously used one in the subsequent calculations. If accepted
as usable, then the value of B is stored in the first position of
a list of values, the stack that is indexed by bearing, after
the previous values in the bearing have been moved up one position; if
this signal replaces an earlier, weaker one, then the weaker one is removed
from the stack and the previously plotted pixel erased. A maximum
of spb (< 44) values can be saved in each bearing.
For this stroke, the code displays on the left portion of the screen the
value of |e1/B|, which is used in adjusting
the E-field gain in the Antenna Array circuit box, the value of B,
and the bearing, expressed in the standard navigational format of 0
degrees for North, 90 degrees for East, 180 degrees for South, and 270
degrees for West. It also calculates, but does not yet display, a
first guess of the Estimated Distance (km) given by the formula:
http://www.met.tamu.edu/personnel/students/weather/station.html
http://www.realestate3d.com/gps/uslatlongdegmin.htm
http://www.bcca.org/misc/qiblih/latlong_us.html
http://www.bcca.org/misc/qiblih/latlong_ca.html
2) The stroke is deemed intracloud if |e2/e1| > mrref!, a
user-set parameter provided in param.txt. Ideally this parameter
would be much less than 1, but our experience indicates that values between
0.3 and 1.0 may be used successfully.
3) The stroke is deemed return if |e2/e1| < mrref!.
in which the user-set parameters are: dxconst&, which is the proportionality constant that is multiplied by the bearing-dependent values sitecor provided in file sitecor.txt; eksp! is a value near 1.0, which we have varied during testing between 0.8 and 1.5; and pxlofst is a value of 5 or less that helps to plot very strong, nearby lightning strokes more accurately. The value AVGB is a simple average of all the signal magnitudes in the bearing of interest. This first-guess distance value is required in the next step.
To estimate the screen coordinates for the next pixel plot, the observations
in the bearing of interest as well as those in neighboring bearings are
used. This radial averaging helps considerably to produce lines
of activity with greatly reduced scatter; because of the considerable variability
of the signal strength of lightning within a thunderstorm cell or group
of cells, we have found that a large number of observations, ideally greater
than 100, are required to produce a reasonable average. Because the
code can keep only a maximum number of spb = 44 signals per bearing,
radial averaging allows the use of enough data to better ensure a robust
average. First, the number of adjacent bearings whose data
will be used in the radial averaging is determined. If the above
distance estimate is less than dist2 (~250 km), then averaging of
data within +8 degrees is used (Case 3); if less than dist1
(~500 km), then averaging of data within +4 degrees is used (Case
2); if less than dist0, then averaging of data within +2
degrees is used (Case 1); otherwise, no radial average is used (Case 0).
These three critical distance values are set in param.txt.
Next, in each required bearing, the trimmed mean of the B values
is calculated. In a trimmed mean, percentages of the largest and smallest
values are not used; these percentages, rejbig! and rejsml!,
are generally each between 0.0 and 0.3, and they are set in param.txt.
Next the values for the appropriate bearings are averaged using a set of
Gaussian weights. The resulting weighted average SBAR is used
to determine the distance in pixel units from the map center; 500 km corresponds
to 200 pixels in the standard 640 x 480 VGA screen mode used. A power
law of the following form is used:
and the estimated distance in kilometers, given by 2.5 times this value, is displayed under the bearing value on the left portion of the screen.
For the above pixel distance to be used to plot a new pixel, the distance must be less than 220 pixels, which is 20 pixels outside the 500 km range circle. If the number of observations in the bearing exceeds the value rstp (set in param.txt and often as low as 3), then the estimated location of the lightning activity is plotted as a yellow pixel; if not, then black is used. If the distance is less than 220 pixels, then the code determines whether the most recent estimated distance differs by less than a specified percentage of the average distance calculated previously in that bearing. To be accepted, the most recent distance must be within trail0 % (default value is 16%) if the number of strokes per bearing is less than or equal to activ = 2*rstp; or trail1 % (default 12%) if between activ = 2*rstp and 2*activ = 4*rstp; or trail2 % (default 8%) if the number is greater than 2*activ = 4*rstp; these percentages are set in param.txt. This trailclipping option is used to reduce the number of widely spaced plots (trailers) that tend to occur when a new cell appears on a bearing. Generally a tighter plot of yellow pixels occurs when this clipping of trailers is used.
In both modes, the code next updates various stroke statistics, some of which (e2, e1, and |e2/e1|) are always provided and others (NR strokes this minute and No. (of NR) in bearing) are updated only if there is a negative return stroke. A graph of the number of NR strokes per minute in the lower right corner and the current or archived time (using the time zone given by the variable timezone$ in param.txt) and date are always given. This information is all that is provided if the diagnostic parameter diag = 0; if diag is set to 1, then added to this information at the bottom of the map is the number of strokes of each type during the previous avghr (default 2) hours as well as the number of strokes diagnosed as part of a single flash series (as either weaker or stronger than the earlier one in that series); if diag = 2 then a long list of diagnostic parameter values are given on the right and top parts of the screen as well. The initial setting of diag is provided in param.txt. If the archiving option given by arch is set in param.txt, then live data are written to the file MMDDYY.log in the path path$. The program then restarts the loop by either checking the Experimenter for new data (Live mode) or reading another line of data (Archived mode).
At regular intervals, the attenuator is turned on for one minute. The attenuator must be turned on to detect nearby lightning whose signal magnitudes can exceed those detected when the system is running in the normal mode. When the attenuator is on, the value of dxconst& in the above formulas is multiplied by the user-set ratio attenrat!; so far, we have only tested values of 1.0 for this multiplier. Preliminary tests with the unit in Kansas have shown that when this cycling of the attenuator is done every 3 or 4 minutes, then both nearby and distant lightning activity can be detected. The cycling interval, in minutes, is given by minattenon and is set in param.txt; it should be a value that evenly divides 60 so that all the intervals during which the attenuator is off are of equal length.
We have tested the utility of many of the user-specified parameters, but their optimal determination remains an area of active research at Penn State, part of which is currently being done by MS student David Mazeroski. So far, all values of sitecor in sitecor.txt have been set to 1.0. The purpose of sitecor is to correct for the well-known site errors; these errors arise from a variety of causes and lead to bearing-dependent changes in the average magnetic signal magnitude. Also, the best value of the power eksp! is by no means fully settled; when set equal to 1.0, we have successfully used values of dxconst& between 20,000 and 35,000 (default is 28000). Values of eksp! > 1.0 require larger values of dxconst&. For example, in one study by 1998 PSU graduate Paul Torpey comparing NLDN-derived distances from Walker Building with GP-1 average signal magnitudes, he found eksp! = 1.5 with dxconst& = 445,000 gave the best results when all values in the bearing where averaged (that is, the trimmed mean was the same as the simple mean). When he used a trimmed mean, he generally found that smaller values of both eksp! and dxconst& were needed; he also found that the best ones varied with bearing. Certainly, a lot more work is needed on this phase of the calibration.
Users should expect to invest at least a full year of operation of their GP-1 to provide a firm basis for the values of these constants. Calibration can be done crudely using the ubiquitous radar data supplied by WSI on the World Wide Web or can be done better and not too expensively using hourly summary lightning data from weather data providers such as Weatherbank. We are able to calibrate the GP-1 installations in Pennsylvania and Kansas using NLDN data supplied by Unidata to the Department of Meteorology at Penn State.
The user-specified display options and parameter values are provided the program via the file param.txt. Many of these can be changed on the fly, while the program is running. All users are encouraged to vary these values to see how they affect the plot quality; they may be invoked in either Live or Archive mode. Changing them in live mode will allow one to relatively quickly determine the range of values that give usable estimates of the location of lighting activity in the vicinity of the GP-1 site.