Campbell CR3000 Micrologger, Руководство оператора

Страница: 423 / 644

Section 8. Operation
423
2. Digital trigger — a digital trigger, rather than a clock, can provide the
synchronization signal. When cabling can be run from CR3000 to CR3000,
each CR3000 can catch the rising edge of a digital pulse from the master
CR3000 and synchronize measurements or other functions, using the
WaitDigTrig() instructions, independent of CR3000 clocks or data time
stamps. When programs are running in pipeline mode, measurements can be
synchronized to within a few microseconds. See WaitDigTrig Scans
(p. 166).
3. PakBus
(p. 82)
commands — the CR3000 is a PakBus device, so it is capable of
being a node in a PakBus network. Node clocks in a PakBus network are
synchronized using the SendGetVariable(), ClockReport(), or
PakBusClock() commands. The CR3000 clock has a resolution of 10 ms,
which is the resolution used by PakBus clock-sync functions. In networks
without routers, repeaters, or retries, the communication time will cause an
additional error (typically a few 10s of milliseconds). PakBus clock
commands set the time at the end of a scan to minimize the chance of skipping
a record to a data table. This is not the same clock check process used by
LoggerNet as it does not use average round trip calculations to try to account
for network connection latency.
4. Radios — A PakBus enabled radio network has an advantage over Ethernet in
that ClockReport() can be broadcast to all dataloggers in the network
simultaneously. Each will set its clock with a single PakBus broadcast from
the master. Each datalogger in the network must be programmed with a
PakBusClock() instruction.
Note Use of PakBus clock functions re-synchronizes the Scan()
instruction. Use should not exceed once per minute. CR3000 clocks drift
at a slow enough rate that a ClockReport() once per minute should be
sufficient to keep clocks within 30 ms of each other.
With any synchronization method, care should be taken as to when and
how things are executed. Nudging the clock can cause skipped scans or
skipped records if the change is made at the wrong time or changed by
too much.
5. GPS — clocks in CR3000s can be synchronized to within about 10 ms of each
other using the GPS() instruction. CR3000s built since October of 2008 (serial
numbers ≥ [3168]) can be synchronized within a few microseconds of each
other and within ≈200 µs of UTC. While a GPS signal is available, the
CR3000 essentially uses the GPS as its continuous clock source, so the
chances of jumps in system time and skipped records are minimized.
6. Ethernet — any CR3000 with a network connection (internet, GPRS, private
network) can synchronize its clock relative to Coordinated Universal Time
(UTC) using the NetworkTimeProtocol() instruction. Precisions are usually
maintained to within 10 ms. The NTP server could be another logger or any
NTP server (such as an email server or nist.gov). Try to use a local server —
something where communication latency is low, or, at least, consistent. Also,
try not to execute the NetworkTimeProtocol() at the top of a scan; try to ask
for the server time between even seconds.