Universal Time Is Your Friend; System Logs - Obvius, LLC A7810 Installation And Operation Manual

Acquilite emb - data acquisition server
Hide thumbs Also See for A7810:
Table of Contents

Advertisement

Time Server: Specify the DNS name or IP address of your time server. The default "time.obvius.com" can be used if the
AcquiLite has a connection to the Internet. The AcquiLite will attempt to synchronize time with the time server every
upload session. This will ensure that the clock is checked and adjusted at a minimum of once per day. Typically, the
synchronization will align the clock to within +-1 second of the internet time source or atomic clock. 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. The time server time.obvius.com supports both NTP and Rdate time protocols. If you use a GSM-connected
system, you will probably need to use Rdate. NTP is blocked by many cellular service carriers.

Universal Time Is Your Friend

Log data is stored in UTC time. 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 AcquiLite, 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 AcquiLite exists, or Local to where the data is stored? If local to the
AcquiLite, you must shift each AcquiLite 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. In other words, 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:00am. This can cause problems if you are calculating
demand values based on consumption.
5) Converting Local time to any other timezone 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. ie:
SELECT * from TABLE where time > '2003-01-01 08:00:00' and time < '2003-01-02 08:00:00'
Note that 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. For
example, 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 timestamps 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 AcquiLite 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 AcquiLite 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 AcquiLite 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 AcquiLite.
Page 19
A7810 AcquiLite – Data Acquisition Server

Advertisement

Table of Contents
loading

Table of Contents