Src-perl-loggerdata

loggerdata.pl

The loggerdata.pl script is the workhorse of WERC's data gathering system from CR10X loggers, and besides the querylogger.pl script is the only script we've written around the Campbell::Comm module.

See below (or elsewhere??) for the #data site architecture assumed by the system.

Like #querylogger.pl, loggerdata.pl runs in a non-interactive or batch mode. But where the former program is driven according to the set of commands provided on the command line, the latter is hard-wired to follow a set sequence of commands.

As with any computer program, the details of what this program does are spelled out in its source code. The following steps are from memory, and should be confirmed...

• a connection is established to the datalogger
• several escape characters are sent in case the datalogger has been left in
• the datalogger command prompt, "*" is obtained
• the "next data memory location" (DSP) is retrieved from the site state o
• the datalogger's current data memory position (MPTR) is obtained
• the G logger telecommunications command is used to set the MPTR to
• data is requested in either ASCII (the D command) or binary (the F
• incoming data is integrity-checked using checksums or signatures
• confirmed-good data is stored on disk
• update the stored DSP state information
• repeat the above data query steps until:
  • the DSP value reaches the logger's MPTR
  • the query times out
  • the allowed processing time for the session elapses
• query the datalogger's time
  • if the logger time is off by more than a specified amount (e.g., 10 seconds),
• if the logger program hasn't been downloaded for greater than a specified time
  • store the logger program to a version control system (RCS)
• query and store the datalogger flags settings
• disconnect from the remote logger
• compose a log message summarizing the session
  • print the log message if the session has been run by a user
  • append the log message to the site log file

In summary, the loggerdata.pl program:

• tries to download data from the last available location
  • all data retrieved is integrity-checked, then stored
• checks (& maybe sets) the time
• maybe downloads the datalogger's current program

In general, we make every attempt to ensure that data is downloaded as it exists on the datalogger, and safely stored on the data-gathering computer. Data is not skipped; in particular, if a remote site has "fallen behind", the program will patiently and persistently try to bring the local (on-computer) data store in line with the remote logger.

The datalogger's time setting is of particular importance mainly so that connection times can be kept in synch, assuming that the radios are powered on only at certain times. Of course, another benefit in checking/settin the logger's time is that the stored data timestamps are meaningful in an absolute sense -- but note that this could also be achieved by only checking (and not setting) the time.