Badger Meter Model 3700 Data Acquisition Server User Manual

Page 15

Advertising
background image

15

Processes
The system process table is shown in both tree and tabular
formats. The process list is useful when contacting Badger
Meter Technical Support.

date and Time
The Model 3700 keeps time using UTC or Universal time. All
log files are recorded in UTC time as well. Time stamps shown
on the Model 3700 local configuration pages are converted to
local time for the convenience of the installer. The date/time
configuration page provides the following options.

date/Time: In UTC and Local time.
date/Time: Dropdown menus to select the current (Local) time
manually.
Timezone: a drop down list of the supported time zones.
Time Sync Protocol: Select NTP or Rdate. Most Linux/Unix
systems provide Rdate, however many provide NTP as well.
Windows domain servers can also provide NTP. If possible use
NTP as it is a more robust protocol.
Time Server: Specify the DNS name or IP address of your time
server. You may need to verify if your firewall will allow NTP or
Rdate packets to pass through. Generally, it is better to use a
local time server if possible.

universal Time Is your Friend
Log data is stored in UTC time. UTC is sometimes referred to as
Greenwich Mean Time (GMT). This allows data collection services
such as BMO to collect data from multiple sites in different time
zones. If you are operating your own database system to store
log data from the Model 3700, it is best to store the data in UTC
time in the database as well, and only convert it to local time when
generating the final report or graph for the user.

If you store data in local time, you will have the following
issues.

1) Local time is relative. Is local the time where the Model

3700 exists, or local to where the data is stored. If local to
the Model 3700, you must shift each Model 3700 data set
depending on its location.

2) There are about 11 time zones in the US. Some observe

DST, others do not. These include Alaska, Aleutian, Arizona,
Central, Eastern, Hawaii, Indiana, Michigan, Mountain,
Pacific, and Samoa.

3) When converting to local time, there will be one hour of

overlapping data in the fall when the time is adjusted for
Daylight Savings time. (i.e. Log entries run 12:45, 1:00, 1:15,
1:30, 1:45, 1:00, 1:15, 1:30, 1:45, 2:00am. This will prevent
you from sorting your data by time in your database.)

4) In the spring, you will have a gap in the data from 1:59 to

3:00 am. This can cause problems if you are calculating
demand values based on consumption.

5) Converting local time to any other time zone usually involves

converting it to UTC first.

Using UTC time solves these problems elegantly. The best
practice is to store data in the database in UTC format and then
convert the information when generating a report for the user.

For example, if you wish to draw a graph of KW over time, prompt
the user for a date range, say Jan 1 midnight to Jan 2 midnight.
Take the user specified end points and convert these times from

local time to UTC. Next, create an SqL query using the new
UTC formatted data as your select statement. i.e.:

SELECT * from TABLE where time > ‘2003-01-01 08:00:00’

and time < ‘2003-01-02 08:00:00’

Note the time is 8 hours ahead of local time. This example is for
Pacific which is 8 hours off from UTC. This will return a list of data
points between the two specified time ranges. Next, plot the data
on a graph, using the UTC times for start and end points. Lastly,
when drawing the ‘time’ legend on the graph, convert the values
back to Local time before displaying. Ie, 2003-01-01 00:00:00 to
2003-01-02 00:00:00. Any division lines on the time axis can be
handled the same way. The advantage of using this technique is
that it will properly draw a graph across DST change boundaries.
The graph axis is based on UTC time with no DST, and will not
show a gap or overlap a the time of the change. The axis labeling
will be correct as well, matching the UTC times precisely.

Another way to handle the conversion is to query and convert
all the returned time stamps to local time before drawing the
graph. This is useful if you do not have detailed control over the
graph legend drawing process. This technique will not properly
graph across DST changes as the graph is based on local time
including DST changes.

System Logs
The Model 3700 can keep several log files that report the general
operation of the system, not related to the normal data logs.
These include the following:

debug Messages: The Model 3700 can run a Syslog process
to record more detailed information about its operations,
however this log consumes vast quantities of memory quickly,
and is disabled by default. Click the Start Log button to enable
the feature. Click the End Log button to disable.
NOTE: when the Model 3700 is rebooted, the debug log will
be disabled on startup.
kernel Boot log: Startup messages about the Linux
operating system startup. This log shows what hardware
items were detected and initialized.
Ftp Connection log: This log shows a list of files transferred
by FTP on the Model 3700.
Last data upload log: This log file contains a report from
the last data upload attempt to remote database/webservers
such as BMO. This log will show if any log files are being
rejected by the dabase/webserver, or if the network is not
allowing a connection.
Last Modem Connection log: This log file shows the details
of the modem operation including modem connection quality
parameters. This is updated ever time the modem makes a
dial-in or dial-out connection.
Time Change Log: This log contains a list of time change
events. When the Model 3700 system clock is changed either
manually or by automated time sync, and the change is more
than a few seconds, the event is recorded here.
System Boot Log: This log shows when the Model 3700 was
started, and lists process events such as remote logins, or
logger process restarts. This log is most useful for detecting
when the Model 3700 was restarted, and whether there was
a proper shutdown event prior to rebooting (if not, possibly
a power outage).
Start/End logging: This button allows the user to start
detailed logging or disable it if it is running.

Advertising