Instruction manual

7-1
SECTION 7. DATA COLLECTION (DBSELECT)
DBSelect is used to select the data for archival or routing to a different application or a different computer.
7.1 POLLING, HOLE DETECTION, AND
HOLE COLLECTION THEORY
The data collection done by DBSelect consists
of two processes; polling and hole collection.
DBSelect makes full use of polled data since it
provides the most efficient means of data
collection. DBSelect will also optionally use
hole collection to collect any data unavailable
with polling.
After the user specifies what data is needed,
DBSelect sends a description of the data it
requires to DLSMGR. DLSMGR combines this
request with any requests for data from any
other programs (i.e., RTM) and advises each
datalogger what data is required from it. This is
done with a command known as a "Data
Advise". After being advised, the dataloggers
are checked for Data Advise data or "polled" at
the user specified polling interval. When polled,
the datalogger returns any advise data it has
stored since the last time it was polled. Since
the datalogger was advised before polling only a
simple short exchange is needed to check for
new data. In RF a poll can be broadcast.
When only polling is done, data stored in the
CR10T before the Data Advise will not be
collected. Despite retries, any data missed
because of adverse conditions encountered
during the polling process will not be collected
by polling. These holes may be acceptable if
receiving new data (for DBSelect or RTM) as
rapidly as possible is more important than
having a complete archive of old data. If it is
desirable to maintain a complete archive of
data, hole collection should be enabled along
with polling. When hole collection is enabled,
DBSelect will attempt to collect any data
records it determines are missing from the data
collected by polling (holes). Typically hole
collection is needed to collect data caused by
the following events:
When first starting DBSelect, the data
stored since the datalogger was
programmed until it receives a new "Data
Advise" (containing DBSelects
requirements) will be a hole.
If DBSelect is stopped, the data stored
while DBSelect is stopped up to the new
Data Advise will be a hole.
If DBSelect or any other program is
changed so its data requirement from a
datalogger changes, a new Data Advise will
be sent to that station. Changing from the
old Advise to the new Advise may cause a
hole that will be hole collected.
When a program is downloaded to a data-
logger or if data cannot be collected for a long
period from a datalogger, it will cancel the
current data advise. The data stored will be a
hole until it receives a new Data Advise.
Any data sent from the datalogger but not
received or not correctly received by
DLSMGR (i.e., signature fails) will be a
hole. These occurrences are minimized by
local retries, signature checking, and error
detection.
Using hole collection, DBSelect can collect the
specific data records that are missing. Hole
collection happens concurrently with polling,
allowing newly stored data and older hole data
to be collected at the same time. Programs
requiring new data do not have to wait for the
missing hole data to be collected. The hole
collection process is slower and uses more
system resources than polling. In a normally
functioning network most data will be collected
with polling. Hole collection is the infrequent
exception, usually occurring as the result of a
user initiated change and occurs with small
holes that are rapidly filled. Usually, it is
possible to use hole collection and polling
without sacrificing timely data collection.
A user-entered polling interval (entered in
NetAdmin) determines how often the CR10T is
polled for data. Specifying a short interval will
reduce the time the stored data waits in the
CR10T before it collected thus reducing the
time before it is received by RTMS. However
short intervals (faster polls) also cause an
increase in network activity and battery drain
and can affect how long hole collection takes.