Welcome to XC Desktop

XConnect is Sutron Corporation's latest data collection, data processing and data storage software. Built on the strong principles of PcBase2, XConnect is compliant with today's 32-bit Windows operating systems and provides new tools and options for the user.

XConnect is a collection of executables designed to provide a complete solution for data collection, data handling, data viewing and data storage.

XC Desktop is the key application used to configure a XConnect system. XC Desktop connects to XC Setup to display all setup information contained in the INI file. Additionally, if the data storage option is a database, XC Desktop provides screens for editing the information in the data tables.

XC Desktop can connect to a local or remote XC Setup. The XC Desktop graphical user interface (GUI) employs standard windows controls and features to assist the user in completing his/her system configuration for data retrieval, data processing and data storage.

XC Desktop contains information that reflects the data loggers in the field and their sensor configurations. The settings in XC Desktop for the stations and sensors have to reflect closely with the field data logger settings. Remember, XConnect interprets data received from the field, it has to know something about the order and format of what it is receiving.

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Moving around in XC Desktop

The XC Desktop application consists of these main areas:

  • The Menu Bar provides access to all user-controllable functions within the application.

  • The Toolbar provides one-click access to important functions.

  • The System View provides the user with a tree view representation of the XConnect stations. Expanding the tree displays stations, sensors, and poll groups as well as system applications.

  • The List View or Setup widow provides the user with informational or error messages related to data storage.

Click an area on the image below for more information.

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Getting Started...

XC Desktop is where you will invest most of your time in configuring your XConnect system. Remember, an XConnect system consists of stations, sensors, communication ports, how or when to communicate with them and where to store the data. XC Desktop is where you will be describing all of these components. So,

  • know what you want the system to do (conventional or satellite system)

  • have all your field station setup information handy

  • determine how you want your data storage organized

All the information entered in XC Desktop is transferred directly to XC Setup where it will keep it in memory for any XConnect module requiring setup information. These parameters are also stored into an INI file controlled by XC Setup.


Upgrading PcBase/PcBase2 to XConnect

Upgrading your PcBase or PcBase2 system to XConnect only requires a few steps. XConnect continues to use the INI file like PcBase2, therefore all the hardwork to create the settings in the INI file is not lost. Follow these steps to upgrade your PcBase/PcBase2 system to XConnect.

  1. Install XConnect.

  2. Using Windows Explorer, copy the PcBase2.ini file to the XConnect installation directory. The PcBase2.ini file will either be in the PcBase2 installation directory or in the Windows directory.

  3. In Windows Explorer, rename the XConnect.ini file in the XConnect directory to XConnect.old.

  4. Rename the PcBase2.ini file to XConnect.ini.

  5. If you plan to switch to using a database to store your XConnect data, first configure the Data Source (ODBC) reference. Sutron strongly recommends changing to the database data storage option (i.e., Microsoft Access database). The database option provides the user with increased access to the data by local users and networked users via a standard interface. A simple database is Microsoft Access. The Microsoft Access application is not required to store data to an Access database. The Microsoft Windows provides many drivers as a part of the operating system.

If the you wish to continue with the PcBase2 binary data files, proceed to the next step.

  6. Open XC Desktop by clicking Start|Programs|XConnect|XC Desktop. The user will be prompted to connect to the local XC Setup or a remote. Select the local XC Setup option.

  7. XC Desktop will automatically launch XC Setup. XC Setup will, by default, read the XConnect.ini file. XC Desktop will open and display the configuration settings.

  8. Review the stations, sensors, pollgroups and com ports configurations.

  9. If the existing telemetry for your system is modem for a conventional system, please go to the Communications Ports node ( [image]). XConnect has slightly changed the way communication ports are added to the system. This step is only required if you are using a modem to communicate with your data loggers. If you are not using a modem or you have a satellite system, go directly to step 12.

  10. Create a new modem communication port. Refer to Defining com ports topic to add a modem communication port.

  11. After creating the modem communication port, go to the Station Setup window for each station and select the new modem port.

  12. Click on the System Init ( [image]) node. The data storage option is currently set to None. Select the desired storage option. From the Tools main menu, select Save Changes.

  13. Click the Data Storage System ( [image]) node. Configure the parameters applicable for the data storage option selected. Refer to the Configuring data storage topic for further details. After changes have been made, from the Tools main menu, select Save Changes.

  14. Review the poll group setup under the Poll Groups ( [image]) node. Check the Clients parameter on the Poll Group Setup window. Delete any clients that will no longer be used in XConnect such as Data Server or Logger.

  15. Review the XC Rtu setup window (for conventional systems) or XC Decode setup window (for satellite systems). Review the directory paths, modify as necessary. Review the Run parameter and determine if the applications listed on the Run parameter line are still required.

  16. Upgrade completed! From the main menu, select File|Startup to start up XConnect servers.


Configuring a new XConnect system

Getting Started...

XC Desktop is where you will invest most of your time in configuring your XConnect system. Remember, an XConnect system consists of stations, sensors, communication ports, how or when to communicate with them and where to store the data. XC Desktop is where you will be describing all of these components. So,

  • know what you want the system to do (conventional or satellite system)

  • have all your field station setup information handy

  • determine how you want your data storage organized

All the information entered in XC Desktop is transferred directly to XC Setup where it will keep it in memory for any XConnect module requiring setup information. These parameters are also stored into an INI file controlled by XC Setup.


Conventional Systems

Sutron data loggers using modem, radio, cell phone, or direct serial cable to communicate with XConnect are considered conventional systems. XConnect will send commands to the data loggers via the communication devices using Sutron Standard Protocol (SSP). SSP is synonymous with conventional systems. Conventional systems are also two-way systems - two-way communications. XConnect will send a data request/command to the Sutron data loggers and the data logger will send a response. The XConnect module used in conventional systems is: XC Rtu.

XC Rtu is the XConnect module that understands how to communicate using SSP. XC Rtu handles all necessary serial handshaking and dialing to make a connection prior to sending the SSP message. After the SSP message is dispatched, XC Rtu will wait for a response, process the data and then store it.

Sutron data loggers allow for multiple communications options. So the primary communication method for the data logger may be a satellite transmitter, and the backup may be a modem. In this case, the XConnect system is a hybrid, both a satellite and conventional system.


Satellite Systems

Sutron data loggers using GOES transmitters or SATLINK transmitters are considered satellite systems. Satellite systems are also one-way systems - one-way communications. Sutron data loggers transmit data to a satellite based on the data logger menu settings. XConnect waits to receive the satellite messages indirectly and cannot initiate a satellite message. The XConnect modules used in satellite systems are: XC Mux, XC Daps, XC Decode.

XC Mux is the XConnect module that waits to receive the satellite messages. XC Mux is used with a Sutron Digital Direct Ground Station (DDRGS). The DDRGS can directly receive the satellite messages. XC Mux communicates with the DDRGS to transfer messages from the DDRGS buffer to the PC.

Alternatively, if using the GOES satellite and the DDRGS is absent, XC Daps can download the satellite messages from the NOAA DAPS database. XC Daps automates a telnet session to retrieve the satellite messages.

Both XC Mux and XC Daps store satellite messages in ASCII raw files on the PC. XC Decode will read these raw files, process the data in the messages and store the data.

Sutron data loggers allow for multiple communications options. So the primary communication method for the data logger may be a satellite transmitter, and the backup may be a modem. In this case, the XConnect system is a hybrid, both a satellite and conventional system.


Creating your INI file

To create a XConnect system (INI file) within XC Desktop, follow these easy steps.

  1. System Initialization

  2. Configure Data Storage

  3. Define communication ports

  4. Create stations

  5. Create sensors

For a conventional system:

  6. Create poll groups

  7. Conventional system applications

For a satellite system:

  6. Satellite system applications


System Init

The System Init step is required only once to configure basic system parameters for XConnect. The System Init window can be accessed by clicking on the System Init ( [image]) node of the System Tree. The System Init setup window appears.

The user is asked to answer several questions that help XC Desktop configure low level parameters for the system. Primarily, these questions determine if this is a satellite system or conventional system and what type of data storage will be used. Additionally, the answers to these questions help XC Desktop appropriately enable and disable setup windows and parameters to aid the user in system configuration.

Sutron data loggers allow for multiple communications options. So the primary communication method for the data logger may be a satellite transmitter, and the backup may be a modem. In this case, the XConnect system is a hybrid, both a satellite and conventional system.


Creating Stations

Each station in XConnect and XC Desktop represents a station/data logger in the field. Creating a station can be done one of two ways: manually or automatically. Both ways are very simple. The automatic way requires having a copy of the data logger setup file.

Creating stations manually

Creating stations manually is a very simple process. Follow the steps for your type of system.

Satellite systems

  1. Click on the Stations main node [image] or click on an existing station name to display the Station setup window.

  2. From the main menu, select Tools|New or click on the [image] to add a new station. The Station setup window will appear.

  3. For satellite systems, the Satellite ID is the most important field. Enter the:

    • Station name (name cannot use period character (.))

    • Enable station

    • Satellite ID (8 digit hexadecimal number provide by satellite agency)

  4. If data storage option is a database, click on the Database Fields buttons to configure additional fields.

  5. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

Conventional Systems

  1. Click on the Stations main node [image] or click on an existing station name to display the Station setup window.

  2. From the main menu, select Tools|New or click on the [image] to add a new station. The Station setup window will appear.

  3. For conventional systems, the RTU Unit ID is the most important field. Recall, as a part of the SSP message, is a sender ID and recipient ID field. The receiver name will be the RTU Unit ID.

For example, if using a modem to communicate to the data logger, XConnect could dial the correct phone number, but if the SSP message has the wrong RTU unit ID, the data logger will reject/ignore the message.

  4. Select the primary com port used to communicate with the data logger. Optionally, select secondary com port if data logger has a second/backup communication module configured. If com port does not appear, go to Com Port setup window to create the appropriate com port.

  5. Additional communication parameters may need configuration depending on the type of communications used.

    • For modem communications, enter phone number in Modem Connection Parameters box.

    • For EDACS trunked radio communications, enter in wake and sleep cycles in EDACS Parameters box.

  6. If the data storage option is a database, click on the Database Fields buttons to configure additional fields.

  7. After sensors are created, complete the RTU Sensor Logging Order if you will be performing Date polls to 8200/8210/9000.

Note: The logging order can be determined by selecting View Data|Newest Readings from the 8200/8210/9000 menu. The order the sensors are displayed is the logging order reflected on the station setup window.

  8. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

Creating stations automatically

  1. Copy the data logger setup file (.SET, .SSF) to the PC.

  2. From the main menu, select Import|RTU Setup or click [image] from the tool bar.

  3. Select the setup file (.SET, .SSF).

  4. Complete RTU Unit ID and communication port selection and click OK.

  5. Station and sensors are automatically created. Select station and sensors to verify/modify import parameters.


Creating Sensors

Each station in XConnect and XC Desktop represents a station/data logger in the field. Each sensor value measured/logged in the data logger has a counterpart sensor in XConnect. Creating a sensor can be done one of two ways: manually or automatically. Both ways are very simple. The automatic way requires having a copy of the data logger setup file.

Creating sensors manually

Creating sensors manually is a very simple process. Follow the steps for your type of system.

Satellite systems

  1. To create the first sensor for a station, click on the existing station name to display the Station setup window.

  2. From the main menu, select Tools|Add Sensor to add a new sensor. The Sensor setup window will appear.

  3. To create additional sensors for an station, click on existing station name to display the Station setup window.

  4. From the main menu, select Tools|New or click on the [image] to add a new sensor. The Sensor setup window will appear.

  5. For satellite systems, enter the:

    • Sensor name (name cannot use period character (.))

    • Enable sensor

    • Equation (scaling for right digits, i.e., x/10)

    • Right Digits (should match setting in data logger)

    • Decoding parameters.

  4. If data storage option is a database, click on the Database Fields buttons to configure additional fields.

  5. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

Conventional Systems

  1. To create the first sensor for a station, click on the existing station name to display the Station setup window.

  2. From the main menu, select Tools|Add Sensor to add a new sensor. The Senor setup window will appear.

  3. To create additional sensors for an station, click on existing station name to display the Station setup window.

  4. From the main menu, select Tools|New or click on the [image] to add a new sensor. The Sensor setup window will appear.

  5. For conventional systems, enter the:

    • Sensor name (name cannot use period character (.))

    • Enable sensor

    • Optional equation

    • Right Digits (should match setting in data logger)

  6. The type of polling (Current or Date) affects some of the sensor parameters.

  7. The RTU Sensor name must match to name of the sensor as configured in the data logger for the following:

    • Performing Current data polls (8200/8210/9210).

    • Polling 9210 or XPert data loggers.

  8. If data storage option is a database, click on the Database Fields buttons to configure additional fields.

  9. After all the sensors are created, complete the RTU Sensor Logging Order on the Station setup window if you will be performing Date polls to 8200/8210/9000.

The logging order can be determined by selecting View Data|Newest Readings from the 8200/8210/9000 menu. The order the sensors are display is the logging order reflected on the station setup window.

  10. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

Creating sensors automatically

  1. Copy the data logger setup file (.SET, .SSF) to the PC.

  2. From the main menu, select Import|RTU Setup or click [image] from the tool bar.

  3. Select the setup file (.SET, .SSF).

  4. Compete RTU Unit ID and communication port selection and click OK.

  5. Station and sensors are automatically created. Select station and sensors to verify/modify import parameters.


Defining Com Ports

XConnect communicates with Sutron data loggers and hardware via communication ports/modems installed on the computer. The purpose of XConnect is to remotely communicate with the data loggers/receiving hardware to receive or retrieve data. XConnect needs to know the type of device it will use to communicate and what communication port (com port) it is attached to.

To create a communication port for XConnect:

  1. Click on the Communicatons Ports main node [image] or click on an existing com port to display the Com Port setup window.

  2. From the main menu, select Tools|New or click on the [image] to add a new station. The Create New Com Port dialog box window will appear.

  3. Select the type of communication device you will be using (i.e, Direct, Radio, Modem, DDRGS, ...etc) and click OK.

  4. The Com Port setup window will appear.

  5. For a direct type, select the appropriate baud rate and the com port the data logger is connected to.

  6. For a radio type, select the appropriate baud rate and the com port the radio is connected to.

  7. For a modem type, select the appropriate baud rate and the modem name.

  8. For a virtual type, select COM0. Baud rate is not applicable.

  9. For 100-BPS DDRGS, select the com port the DDRGS hardware is connected to. Select 9600 for the baud rate.

  10. For HDR DDRGS, select the com port the DDRGS hardware is connected to. Select 19200 for the baud rate.

  11. Based on the com port type, parameters will be enabled/disabled. In most cases, the default parameter values will not need modification.

  12. From the main menu, select Tools|Save Changes or click [image] from the tool bar.


Creating Poll Groups

Poll groups are used in conventional systems only. A poll group serves two purposes. First, a poll group describes what type of data XConnect will poll/request. Second, a poll group determines, which groups of stations and how often they will be polled this way. The request is in the form of an SSP message. Creating poll groups involves a few simple steps:

  1. Click on the Poll Groups main node [image] or click on an existing poll group to display the Poll Group Setup window.

  2. From the main menu, select Tools|New or click on the [image] to add a new poll group. The Poll Group setup window will appear.

  3. Required parameters to create a poll group are:

    • Enable poll group.

    • Specify Base Time and Interval of poll group.

    • Select poll type (type of data retrieved from data logger)

    • Stations to send data request to.

  4. From the main menu, select Tools|Save Changes or click [image] from the tool bar.


Configuring Data Storage

Initial data storage selection is done on the System Init setup window. The Data storage setup window is used to configure parameters specific to the data storage option selected. As a reminder of your selection, the data storage option is displayed at the top of the setup window. Return to the System Init window to change the data storage selection.

Click on the Data Storage Systems main node [image] to display the data storage setup window. The Data Storage setup window will have detailed explanations of all fields and storage formats. XConnect provides data storage options of:

  • PcBase2 binary files

  • ASCII Log files

  • EXCEL files

  • XML files

  • Oracle 8i (and higher) database

  • Microsoft® Access database

  • Microsoft® SQL Server database

PcBase2 Binary Files

  1. Enter desired directory of binary files. Click on Browse button to navigate through folders.

  2. From the main menu, select Tools|New or click on the [image] to add a new binary data file.

  3. Enter optional description text for binary file.

  4. Modify Start Date if data from data logger starts prior to the Start Date.

Note: Start date always defaults to the date the file was created. If the data logger is already installed and recording data, and XConnect will retrieve data logged from these prior days, adjust the Start Date back. Otherwise, data will be received by XConnect by NOT stored in the binary data files.

  5. Enter data Interval. This interval should match the logging interval as set in the data logger.

  6. Click desired sensors to the Sensors in Binary File list box. Data files can contain any combination of sensors.

  7. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

ASCII Log/EXCEL/XML

  1. Enter desired output directory of files. Click on Browse button to navigate through folders.

  2. Enter desired filename/filename format (i.e., yyyymmdd.LOG).

Using lower case letters y, m, d, h will substitute in the actual number for the year, month, day or hour, respectively. Any uppercase letters in filename will be preserved.

  3. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

Oracle/Access/SQL Server

  1. Select correct Data Source. If the data source does not appear, go to the Data Sources (ODBC) control applet and configure the database source name. If the database resides on the network, contact your network administrator to assist in configuring the data source.

  2. Enter the user name and password.

This user account will be used by all XConnect modules to access the database.

  3. From the main menu, select Tools|Save Changes or click [image] from the tool bar.


Importing setups

A simple way to automatically create stations and sensors is to import the data logger setups into XC Desktop. Download the data logger setup (.SET, .SSF) after final configuration and testing. As mentioned earlier, XConnect stations and sensors are a reflection of the field stations. It is their data were are retrieving, processing and storing. Thus, their configuration in XConnect must mirror their configuration at the field.

To import a setup file into XConnect:

  1. From the main menu, select Import|RTU Setup or click [image] from the tool bar.

  2. Select the setup file (.SET, .SSF).

  3. Complete RTU Unit ID and communication port selection and click OK.

  4. Station and sensors are automatically created.

  5. Select station and sensors to verify/modify import parameters (especially if an .SSF was imported).

  6. If using database storage option, explicitly save changes to station setup and click OK when prompted to save to database.

Note: Verify RTU Unit ID (conventional system), Satellite ID (satellite system) in station setup window. Verify RTU Unit ID (conventional system) or sensor decoding parameters (satellite system) in the sensor setup window.


Configuring XConnect apps for a Conventional system

Configuring XConnect Applications for a Conventional systems

XC Rtu is the XConnect module used for conventional systems. A conventional system uses Sutron Standard Protocol (SSP) to communicate to Sutron data loggers via direct connect (RS-232), radios or modems. XC Rtu is responsible for:

  1. initializing the radio (keying transmitter), modem (dialing phone number) or serial device (toggling control lines).

  2. sending the SSP message (data request).

  3. waiting for the SSP message (data response).

  4. deciphering the sensor value(s) in the SSP message.

  5. storing sensor value(s).

Configuring XC Rtu

  1. Click on the Conventional Systems main node [image] to display the XC Rtu setup window.

  2. For detailed explanations of all fields, go to the XC Rtu setup window.

  3. The Master ID is the most important field. By default, it is XConnect. If upgrading from a PcBase2 system, use PCBASE as the master ID (field is case insensitive). Just as each data logger has a unit ID, so does XConnect. It is referred to as a Master ID because XConnect will be in charge of the polling time (initiating SSP messages to retrieve data).

  4. Enter the Table path if using lookup/rating tables in the sensor equations.

  5. Most other fields can be left as their defaults.

  6. From the main menu, select Tools|Save Changes or click [image] from the tool bar.


Configuring XConnect apps for a Satellite system

Configuring XConnect Applications for a Satellite systems

XC Decode, XC Mux and XC Daps are the XConnect modules used for satellite systems. A satellite system uses GOES or SATLINK transmitters as the data loggers' main communication device. Also, a Digital Direct Readout Ground Station (DDRGS) may be used to received satellite messages directly.

XC Mux is responsible for:

  1. communicating with a Sutron DDRGS.

  2. requesting messages in the DDRGS buffer.

  3. converting DDRGS raw satellite messages to NESDIS format.

  4. storing raw NESDIS messages into ASCII files on PC.

XC Daps is an optional module which can serve as a backup to XC Mux. Or, if a DDRGS is not a part of the system, can serve the same role as XC Mux. XC Daps is responsible for:

  1. initiating a telnet session to the NOAA DAPS database.

  2. sending DAPS commands to download raw NESDIS messages in DAPS database.

  3. storing raw NESDIS messages into ASCII files on PC.

XC Decode is responsible for:

  1. reading raw ASCII file created by XC Mux and/or XC Daps.

  2. deciphering the sensor value(s) in the raw message.

  3. storing sensor value(s).

Configuring XC Mux

  1. Click on the Satellite Systems main node [image] to display the XConnect satellite modules. Click on XC Mux node to display XC Mux setup window.

  2. For detailed explanations of all fields, go to the XC Mux setup window.

  3. Enter the demod settings as configured in the DDRGS.

  4. Enter the Raw Path where XC Mux will store the raw satellite messages.

  5. Enter the Raw Filename that will describe how XC Mux will create the names of the raw files.

Example 1:

Using lower case letters of yyyymmdd.raw will instruct XC Mux to create filenames using a 4-digit year, 2-digit month and a 2-digit day (i.e. 20030101.raw). Thus, a new raw file will be created each day.

Example 2:

Using lower case letters of yymmddhh.raw will instruct XC Mux to create filenames using a 2-digit year, 2-digit month, a 2-digit day and a 2-digit hour (i.e. 3010112.raw). Thus, a new raw file will be created each hour.

Example 3:

MYDATdd.RAW would create the file MYDAT01.RAW on the first day of the month, MYDAT02.RAW on the second day, and so on until the next month MYDAT01 would be used again. NESmm.RAW would create the file NES01.RAW to contain all the data for January, NES02.RAW to contain all the data for February, and so on until the next month.

Example 4:

yymmddhh.RAW#02 would create a new output file every 2 hours. If the "#02" was left off, a new file would be created every hour. As well, mmddhhmi.RAW#15 would create a new output file every 15 minutes.

  6. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

Configuring XC Decode

  1. Click on the Satellite Systems main node [image] to display the XConnect satellite modules. Click on XC Decode node to display XC Decode setup window.

  2. For detailed explanations of all fields, go to the XC Decode setup window.

  3. Enter the channel settings designating timed or random transmissions.

  4. Enter the Auto Decode Path where XC Decode will read raw satellite message files created by XC Mux/XC Daps.

  5. Enter the Auto Decode File that represents the file extension of the raw satellite message files. XC Decode will read all files with this extension in the Auto Decode Path.

  6. Enter a GMT (Greenwich Mean Time) if you wish to process and store the sensor values with respect to local time.

  7. Enter Decode Base Time and Decode Interval to indicate how often XC Decode will check the Auto Decode Path and the Auto Decode File for new satellite messages.

  8. Enter the Table path if using lookup/rating tables in the sensor equations.

  9. Check Store Quality option if you wish to review and monitor transmission quality values in satellite messages.

For the database storage option, the quality parameters are stored in the XC_GOESQC data tables.

For all other storage options, the quality parameter are stored in ASCII files created daily.

  10. From the main menu, select Tools|Save Changes or click [image] from the tool bar.

Configuring XC Daps

  1. Click on the Satellite Systems main node [image] to display the XConnect satellite modules. Click on XC Daps node to display XC Daps setup window.

  2. For detailed explanations of all fields, go to the XC Daps setup window.

  3. Enter Base Time and Interval to indicate how often XC Daps will open a telnet session and check the NOAA DAPS database new satellite messages.

  4. Enter the Raw Path where XC Mux will store the raw satellite messages.

  5. Enter the Raw Filename that will describe how XC Mux will create the names of the raw files. For example, using lower case letters of yyyymmdd.raw will instruct XC Mux to create filenames using a 4-digit year, 2-digit month and a 2-digit day (i.e. 20030101.raw). Thus, a new raw file will be created each day.

  6. Enter Last Download time as the starting time for downloads. This time is GMT like the DAPS database.

  7. From the main menu, select Tools|Save Changes or click [image] from the tool bar.


Creating Users

Login users are not required to be configured in XConnect. XConnect can support very small system (a few data loggers) to very large systems (hundreds of data loggers). Based on the complexity of the system, there may be a requirement to control the access to the XConnect setup parameters. By default, when XConnect is installed, no users are created and full access is granted to all users. Once a user is created, all users will be required to login into XConnect modules before viewing or modifying parameters.

To create a user:

  1. Click on the Users main node [image] or click on an existing user name to display the Users setup window.

  2. From the main menu, select Tools|New or click on the [image] to add a new user. The User setup window will appear.

  3. Enter in the parameters describing the user, password and select his/her privileges.

  4. From the main menu, select Tools|Save Changes or click [image] from the tool bar.


Using Templates

Templates provide a convenient and powerful way to manage your station and sensor parameters. Understanding and taking advantage of templates helps the user quickly create new stations and maintain existing ones.

A template is a pattern. In our case, it is a pattern of a station or sensor. In many systems, the number of stations can be significant but they are all configured with the same sensors and logging scenario. Thus, we will create one station that will be the pattern or "template" for all the others.

A template can still an active station or sensor. Thus creating a template is the same as creating a station or creating a sensor. After the station or sensor is created, from the main menu select Tools|Make Template. This action now makes the station or sensor available as a "template".

The Templates main node [image] will display the names of all templates. In most cases, the template station will have all the parameters configured except for the RTU Unit ID or Satellite ID which will be unique for the stations.

To use a station template:

  1. Create the station using Tools|New or click on the [image] on the toolbar.

  2. Enter Station name and save changes.

  3. From the main menu, select Tools|Assign Template.

  4. Select a station/sensor template from the list and click Ok.

  5. The template parameters will appear on the station or sensor setup window but will appear in blue.

Note: When parameter values on the station setup window or the sensor setup window are displayed in blue, they are based on a template. The name of the template will be displayed in the right-hand panel of the status bar.

Template parameter values can easily be overridden by typing over the value. The overridden value will appear in black.

A template can be removed by selected Tools|Unassign Template.


System Init parameters

System Init setup window

The System Init setup window represents the parameters used to inform XConnect what modules will be used and how the data will be stored. Answer the questions according to your system.

Click on the System Init main node [image] to the System Init setup window.

System Init setup parameters

  • Is this a conventional system using radio, modem or direct connect? - If the data logger has a radio, modem or a direct cable connected to the data loggers for communication, check this box.

  • Is this a satellite system? - If the data logger has GOES transmitter or a SATLINK transmitter connected to the data logger for communication, check this box.

  • Will you be using DDRGS hardware to receive NESDIS messages? - If you have purchased a Sutron Digiital Direct Readout Ground Station (DDRGS) to receive satellite messages, check this box.

  • Will you be using DAPS Dialer/telnet to receive NESDIS messages? - If you be using XC Daps or DAPS Dialer as a backup to receive NESDIS messages, check this box.

  • What type of Data Storage will be used? - Select the data storage format you will be using.

    • None - No data will be stored. The internal real-time data values and DDE points will be maintained.

    • PcBase2 Binary Files - Data will be stored to legacy PcBase2 binary files.

    • ASCII Log Files - Data will be stored to ASCII comma-separated files .

    • EXCEL Files - Data will be stored similar to the ASCII log files but will be in native Excel format. Caution, the maximum number of records allowed in an Excel file is 65500 records.

    • XML Files - Data will be stored in XML format.

    • Databases

XConnect supports a variety of relational databases. The XConnect database schema is versatile using generic data types.

      • Access - Microsoft Access database.

      • Oracle - Oracle 8i and higher databases.

      • SQL Server - Microsoft SQL Server.

      • HDB (CADSWES) - Special database schema created by CADSWES Corporation. XConnect interfaces with the HDB database using stored procedures, database views and database joins. Stations and all required data type information must be created in the HDB database using HDB tools. XC Desktop will not write directly to the HDB data table. When storing data, a stored procedure will be used. XC Reports and XC DataView will use views and database joins to display data.

      • INSQL (Wonderware) - Special implementation of XConnect tables and Wonderwares INSQL database. XConnect interfaces with the INSQL database using stored procedures, database views and database joins. Sensors must be created in the INSQL TAG table in the form of station.sensor (i.e., XPERT.AT) before adding the sensor in XC Desktop. INSQL will generate a wwTagKey in the TAG table. XConnect will use and require this field when retrieving and storing data. When storing data, a stored procedure will be used. XC Reports and XC DataView will use views and database joins to display data.

  • Store all Real-time data (Current polls/Satellite Random messages)? - If you will be sending Current polls or receiving random satellite messages and want to store the data, check this box.

  • Store all Time tag data (Date polls/Self-timed messages)? - If you will be sending Date or Newest polls or receiving self-timed satellite messages and want to store the data, check this box.

  • Use a No Value Indicator - If a sensor value is returned or decoded with a bad or null value, use the value specified in the No Value Indicator as the sensor value. This allows uses to easily recognize a incorrectly measured or transmitted sensor value.

  • No Value Indicator - This value is used as the sensor value when a bad or missing value is received by XConnect.

The two questions pertaining to storing data will normally always be checked. Typically, any data received by the station will be stored. But, in the cases of the 8200/8210/9000 data loggers, Current poll data can be different from Date poll data. Current poll data is the same as real-time or current sampled data (sample #10 out of 100), where Date poll data is the complete average data (average of all 100 values). Thus, there may be a reason only to store one type of data.


Station setup window

The Station setup window represents the parameters used to configure a station in XConnect. Parameters inform the XConnect module, XC Rtu, how to initiate the communications device, and whether or not to login before sending a SSP message.

Click on the Stations main node [image] or click on an existing station name to display the Station setup window.

Station setup parameters

  • Station - Name of station in XConnect. The station name can be longer than the RTU Unit ID, thus, the station name may or may not be different from the RTU Unit ID. For the database storage option, the station name is limited to 20 characters. For other data storage options, there is no length limitation. Station name cannot use period character (.).

  • Site Type - Type of data logger. Select appropriate Sutron data logger model. For all others, select type Other.

  • Enable - This flag indicates the station is an active station ready to be polled or have data decoded and stored. Stations can be created but left "inactive" until a later date.

  • RTU Unit ID - Data logger Unit ID. Each Sutron data logger has a name/ID. For the 8200/8210/9000, the RTU Unit ID is limited to 8 characters. For the 9210/XPERT, the RTU Unit ID has no limitation on the name but is strongly recommended to limit the name to 10 characters or less to optimize SSP messages. For the database storage option, the unit id is limited to 15 characters.

In a conventional system, each RTU Unit ID must be unique. In an SSP message, XC Rtu will address each data logger by its RTU Unit Id, thus each needs to have a different one. For satellite systems, the Unit ID is not used.

  • Satellite ID - 8-digit hexadecimal ID provided by governing satellite agency. Each data logger will be assigned a satellite ID that will correspond to a transmission time and transmission channel. For obvious reasons, this field is not used in conventional systems.

  • IP Address - 12-digit number assigned by network administrator or wireless service provider. This IP address is used only if communicating through cellular data packet (CDPD) modems or Ericsson EDACS (Enhanced Digital Access Communication System) trunked radio systems.

  • Setup File - Name of setup file used for station (data logger) setup. This field may be left blank. These setup files can also be used to assist the user in creating the station and senors automatically by importing them.

For 9210/XPERT/SATLINK Logger, this field can be used as a reminder of the corresponding setup file downloaded from the data logger after installation.

For 8200/8210/9000, the setup file will be the file sent during a SENDSETUP control command to the data logger. For a GETSETUP control command, the setup data retrieved from the data logger will be saved to the setup file name.

  • Poll Type - Type of data to be requested from the station. Normally, this field is not used. The type of data polled/requested from the data logger is usually configured in the Poll Group setup. Thus, all stations are polled for the same type of data. However, if in the poll group setup, the poll type is None or NoWait, then the poll type can be defined individually and differently for each station.

  • None - No data will be polled/requested.

  • Current - Real-time data will requested. Real-time data represents the last measured values. In the 8200/8210/9000, the last measured values are the same as the values seen while viewing LIVE DATA in the data logger menu setup. Caution, the last measured data may be, when the data request is received, the 40th sample out of 100. In the 9210/XPERT, the last measured data will always be the resultant value from the COMSTAG data block.

  • Date - Logged data will be requested. Logged/time-tagged data is stored in the data logger log with a corresponding time stamp. In the 8200/8210/9000, the time-tagged data is the same as view NEWEST DATA in the data logger menu setup. In the 9210/XPERT, the time-tagged data is the same as the VIEW LOG tab. The date and time of the last data retrieve is stored in the Last Poll field. So, the next poll will start with the Last Poll time.

  • Newest - Logged data will be requested. A Newest data poll retrieves the same data as a Date poll. The difference is who keeps track of the Last Poll time. In the case of a Date poll, XConnect maintains the time field. For a Newest poll, the data logger maintains the time field.

It is recommended to use Date polls. The user has the flexibility/control to adjust this field if data needs to be re-retrieved. The user does not have such access in the data logger in Newest data polls.

  • NoWait - In a normal SSP data request, the message is dispatched and XC Rtu waits for a response. If no response is received before the timeout period, it will retry. After all retries are exhausted, the next SSP message will be dispatched. In NoWait mode, the poll type described in the station setup will be dispatched. Without waiting for a response, it will dispatch the next poll to the next station in the polling list. No retries are performed in the NoWait mode.

  • Concentrator - Check this parameter if this RTU/station is configured as a concentrator. A concentrator RTU will poll for data from other RTUs using GETTAG commands that the base station computer is not able to poll. Then, the base station computer polls the concentrator RTU for all data.

  • Last Poll - Timestamp of last data received by a Date poll. XC Rtu will update this field each time a successful SSP date poll response is received.

  • Hours Ahead - Offset added to the time received by XC Rtu. Hours Ahead can be positive or negative. In most cases, the data logger time when using radios or modems is set to local time. In isolated cases, the data loggers are installed in different time zones. In these cases, the time set in the data loggers will be different. The Hours Ahead offset will allow the offset to be used so all the data will be stored correctly with respect to the XConnect base station local time.

  • Data to Store - In the System Init window, the user can indicate to store ALL real-time data and ALL time-tagged data from all stations. However, if selective data from each station is required, users can select specific data to store from each station: REALTIME, TIMETAG, BOTH.

  • RTU Sensor Logging Order - For 8200/8210/9000 data loggers, when time-tagged data is requested, the format of the SSP response are sets of numbers (sensor values) corresponding to a time stamp. No sensor labels/names are included in the response. The order of the numbers and which sensor they match up is defined by the RTU Sensor Logger Order. For 9210/XPerts with Graphical Setups, the time-tagged responses contains the sensor names. For 9210XPerts with EZSetups, the log is like that of 8210 loggers and will require the Rtu Logger Order to be enterd.

To create a Log ID (Logging Order):

  • Right click while the mouse is in the RTU Logging Order group box and select New. Enter the Log ID. For 8200/8210 data loggers, this value will be 0. For 9000s, refer to the SDL code for the Log ID. For the 9210/XPerts, refer to the EZSetup Log ID.

  • Click the Refresh button ( [image]) in the RTU Logging Order group box. This will fill in the list box with the sensor list. Use the up ( [image]) and down ( [image]) arrows to move the sensors so they reflect the logging order in the data logger.

  • Primary Station Connection Parameters

    • Connection Port - Primary com port or device that XC Rtu will use to communicate with the station.

    • Radio Path - Path to data logger on the primary connection port. Typically, the radio path is the same as the Unit ID. It indicates the route via Sutron data loggers to its destination. Sutron data loggers have the ability to store and forward messages. In a line-of-site (LOS) radio network, to reach a particular data logger, the message must be forward through another one. In this case, the radio path will include the unit id of the repeating data logger (i.e. RPTRID_UNITID).

    • RX Timeout - This parameter represents the seconds to wait before timing out waiting for a response for the primary com port. This is the maximum amount of time XC Rtu will wait for an acknowledgement (ACK) after it has sent an SSP message. This is the same parameter as in the COM Port setup menu. If the default COM Port timeout setting is not sufficient, it can be overridden on a station basis here.

Example: When XC Rtu sends a mail message, an ACK is expected from the data logger.

    • TX Timeout - This parameter represents the seconds to wait before timing out sending a message for the primary com port. This is the maximum amount of time XC Rtu will wait for a response from the data logger. This is the same parameter as in the COM Port setup menu. If the default COM Port setting is not sufficient, it can be overridden on a station basis here.

Example 1: When XC Rtu sends a Current data poll, a response is expected from the data logger before the TX Timeout expires before retrying again.

Example 2: When XC Rtu sends a Date poll, the response can be in multiple SSP messages. After the receipt of each SSP message, XC Rtu sends an ACK to the data logger and then the data logger will send the next packet. If the next packet is not sent within the TX Timeout period, XC Rtu will retry.

  • Secondary Station Connection Parameters

    • Connection Port - Secondary com port or device that XC Rtu will use to communicate with the station.

    • Radio Path - Path to data logger on the secondary connection port. Typically, the radio path is the same as the Unit ID. It indicates the route via Sutron data loggers to its destination. Sutron data loggers have the ability to store and forward messages. So in a line-of-site (LOS) radio network, to reach a particular data logger, the message must be forward through another one. So, in this case, the radio path will include the unit id of the repeating data logger (i.e. RPTRIDUNITID).

    • RX Timeout - Seconds to wait before timing out waiting for a response for the secondary com port. This is the maximum amount of time XC Rtu will wait for a acknowledgement (ACK) after it has sent an SSP message.

    • TX Timeout - Seconds to wait before timing out sending a message for the secondary com port. This is the maximum amount of time XC Rtu will wait for a response from the data logger.

  • Login Parameters

    • Auto Protocol - This parameter indicates whether the data logger is ready to accept SSP protocol messages. For the 8200/8210. in the EEROM setup, if the USER setting is set to PROTOCOL, the Auto Protocol box should be checked. The Sutron data loggers have the advantage to be in a terminal mode corresponding with HyperTerminal or XTerm. If that is the case, Auto Protocol should be unchecked. Auto Protocol refers SSP protocol ready.

    • Login Req'd - This parameter indicates whether the data logger requires a login. For the 8200/8210, in the modem setup menu, if a modem password was entered, then this parameter needs to be checked. The user name will be the RTU Unit ID. For the 9210/XPert, refer to the Control Panel tab. Edit the Users node to specify/create the user name and passwords.

    • User Name - If Login Req'd is checked, then a user name and password is required. The User name will be the data logger Unit ID.

    • Password - For the 8200/8210/9000, the login password will be the password in the Modem Setup menu.

  • Modem Connection Parameters

    • Primary Tel No. - For modem connections, the primary telephone number is associated with the primary communications port.

    • Secondary Tel No. - In some cases, the primary communications will be an internal modem (8200/8210) and the secondary communications may be an external modem. In this case, the external modem will have a secondary telephone number.

    • Init String - Additional station specific extra Hayes commands to send during modem initialization.

    • Hangup String - Additional station specific extra Hayes commands to send during modem hang up.

  • EDACS RDI Parameters

EDACS refers to a Enhanced Digital Access Communication System provided by Ericsson. The radios used by the EDACS system have high current requirements. In order to maintain efficient battery usage, the radios will need to be turned on and turned off. These parameters are defined by the following parameters.

    • Base Time - The Base Time and Interval define the cycle how often to turn the EDACs radios on.

    • Interval - The Base Time and Interval define the cycle how often to turn the EDACs radios on.

    • Dwell - This parameter indicates how long the EDACs radio will be left on.

Station Database setup parameters

For the Database data storage option, additional station fields are available. Click on the Database Parameters button on the Station Setup window to edit station database parameters. For a detailed description of the XConnect database schema, go to the XConnect Database Schema topic under Advanced Topics.

  • Station_ID - 20 characters - Same as Station parameter on station setup window.

  • Enabled - 1 character - Processing/collection enabled for this station Y/N.

  • Unit_ID - 15 characters - Name of data logger and entered in data logger menu.

  • Site_Comment - 32 characters - General purpose string for comments on station.

  • Installation_Date - Date - Date station was installed.

  • Agency - 32 characters - Agency or entity that owns this station.

  • Country - 32 characters - Country where station is located.

  • District - 32 characters - District Name where station is located.

  • City - 32 characters - City Name where station is located.

  • State - 20 characters - State political boundary where station is located.

  • County - 32 characters - County political boundary name where station is located.

  • Basin - 32 characters - Name of river basin where site is located where station is located.

  • Latitude - Number - Stations' latitude in degrees, minutes, seconds.

  • Longitude - Number - Stations' longitude in degrees, minutes, seconds.

  • Elevation - Number - Stations' elevation to 3 decimal precision.

  • Weighting_Factor - Number - Precipitation station weighting for MAP calculation.

  • Satellite_ID - 8 characters - NESDIS/Satellite Identifier.

  • Primary_Channel - Number - Primary satellite transmission channel.

  • Random_Channel - Number 22 - Secondary satellite transmission channel.

  • Reporting_Time - Date - Assigned time slot relative to GMT.

  • Reporting_Interval - Number - Time between transmissions in hours.

  • Last_Update - Date - Time of last data received from station.

  • Tzone_Code - 3 character - ASCII time zone code, e.g. EST.

  • GMT_Offset - Number - Time zone offset from GMT.

  • SHEF_ID - 8 characters - Standard Hydrologic Exchange Format station ID.

  • Image_File_Name - 255 characters - Path to .jpg or some other site picture.

  • Coefficients

    • Coefficient 1 - Number - General purpose coefficient 1.

    • Coefficient 2 - Number - General purpose coefficient 2.

    • Coefficient 3 - Number - General purpose coefficient 3.

  • Generic Station Fields

    • Alternate_Char_ID_1 - 10 characters - Space for alternate character ID.

    • Alternate_Char_ID_2 - 10 characters - Space for alternate character ID.

    • GPString1 - 20 characters - General purpose string 1.

    • GPString2 - 20 characters - General purpose string 2.

    • GPNumber1 - Number - General purpose number 1.

    • GPNumber2 - Number - General purpose number 2.


Sensor setup parameters

Valid operators are:

+, -, *, /, OR, XOR, AND, MOD, SHR, SHL, >, >=, =, <=, <>, <

Valid functions are:

ARCTAN | Arc tangent of number and converted to radians.
ABS | Absolute value of number.
ASCII | For satellite systems, indicates that the decoding format used to decode that sensor was ASCII and not 6BIT.
COS | Converts number to radians and take cosine of number.
EXP | Exponential of number.
INT | Returns only integer portion of number.
LOG | Base 10 logarithm of number.
LN | Natural logarithm of number.
NOT | Takes logical opposite of value.
RND | Random number using truncated value as seed.
ROUND | Round number to nearest integer.
SIN | Converts number to radians and take sine of number.
SQRT | Takes square root of number.
TAN | Converts number to radians and takes tangent of number
TABLE(Name, X) | Indicates a lookup table will be used. TABLE(Name, X). Name represents the name of the table only, X represents the incoming sensor value. The path is represented by the Table Path parameter.
TRUNC | Truncates number to an integer.

Valid functions for database data storage options:

The functions below can be used only when the user selects database as the data storage options. These functions allow the user to retrieve coefficients/constants stored in the database record of the station or sensor.

DBTABLE(Name, X) | Indicates a lookup table will be used, however the rating table name will be retrieved from the database. Name represents the name of the sensor (i.e, STATION.STAGE) and X represents the incoming sensor value.
SHIFT(Name) | Retrieves the SHIFT value stored in the database for the sensor. Name represents then name of the sensor (i.e, STATION.STAGE).
OFFSET(Name) | Retrieves the OFFSET value stored in the database for the sensor. Name represents the name of the sensor (i.e, STATION.STAGE).
ELEV(Name) | Retrieves the ELEV value stored in the database for the sensor. Name represents the name of the sensor (i.e, STATION.STAGE).
STN_COEFF(Name, N) | Retrieves a COEFFICIENT value stored in the database for the station. Name represents the name of the station (i.e, STATION) and N represents the coefficient number (1-3).
SNS_COEFF(Name, N) | Retrieves a COEFFICIENT value stored in the database for the sensor. Name represents the name of the sensor (i.e, STATION.SENSOR) and N represents the coefficient number (1-5).
STN_GPN(Name, N) | Retrieves a Generic Number value stored in the database for the station. Name represents the name of the station (i.e, STATION) and N represents the Generic Number (1-2).
STN_GPN(Name, N) | Retrieves a Generic Number value stored in the database for the sensor. Name represents the name of the sensor (i.e, STATION.SENSOR) and N represents the Generic Number (1-2).

None - Alarm will not be evaluated.

Above - Values will be checked to see when they are above the corresponding alarm limit.

Below - Values will be checked to see when they are below the corresponding alarm limit.

None - Alarm will not be evaluated.

Above - Values will be checked to see when they are above the corresponding alarm limit.

Below - Values will be checked to see when they are below the corresponding alarm limit.

None - Alarm will not be evaluated.

Above - Values will be checked to see when they are above the corresponding alarm limit.

Below - Values will be checked to see when they are below the corresponding alarm limit.

None - Alarm will not be evaluated.

Above - Values will be checked to see when they are above the corresponding alarm limit.

Below - Values will be checked to see when they are below the corresponding alarm limit.

None - Alarm will not be evaluated.

On - Values will be checked to see when match the corresponding alarm limit.

None - Alarm will not be evaluated.

Above - Values will be checked to see when they are above the corresponding alarm limit.

Below - Values will be checked to see when they are below the corresponding alarm limit.

None - Alarm will not be evaluated.

On - Values will be checked to see when match the corresponding alarm limit.

Sensor Setup window

The sensor setup window represents the parameters used to configure a sensor in XConnect. Parameters inform the XConnect module, XC Rtu, how to process the data in the received SSP message.

Click on an existing sensor name or select Tools|Add Sensor from the Station setup window to display the Sensor setup window.

Sensor setup parameters

  • Sensor - Name of sensor in the XConnect system. This can be different or be the same as the RTU Sensor Name. The sensor name can be much longer than the RTU sensor name. For the database storage option, the sensor name is limited to 12 characters. For other data storage options, there is no length limitation. Sensor name cannot use period character (.).

  • RTU Sensor Name - Sensor name as declared in the data logger. For the 8200/8210/9000, the RTU Sensor is limited to 10 characters. For the 9210/XPERT, the RTU Sensor name has no limitation on the name but it is strongly recommended to limit the name to 10 characters or less to optimize SSP messages

  • Enable - This flag indicates the sensor is an active sensor ready to have data decoded and stored. Sensors can be created but left "inactive" until a later date.

  • IsText - By default, sensor data is numerical. However, the 9210 and XLite (and perhaps data loggers by other vendors) can transmit text representing sensor data. If this is the case, check this box. This flag can only be used when using the database data storage option. The text data will be stored in the XC_TXTDATA1 data table.

  • Equation - If additional processing is required to the incoming sensor value, enter the equation here. The equation is limited to a single polynomial equation where the incoming sensor value is represented by X. The equation is case-insensitive.

Example 1:

X/100

This example will divide the incoming value (X) by 100. This is used frequently in satellite systems to scale right digits (2) factor back into the decoded sensor value.

Example 2:

LOG(X)

This example takes the base 10 logarithm of X.

Example 3:

((X< .5)*(X*0)) + ((X >= .5)*(X*0+1))

This example will evaluate the incoming sensor value (X) in two parts. First, if the sensor value is less than 0.5, it will multiply it by 0. Second, if the sensor is greater than or equal to 0.5, it will multiply the value by 0 and add one. Essentially, this equation wants to return a sensor value of 0 or 1 if the value is below or above 0.5.

Note: When an equation has multiple parts, all parts of the equation will be checked. Make sure that no part of the equation will not result in an undefined/invalid value (such as a divide by 0).

Example 4:

Table(Guaratb,x/100)

This example uses a rating table. The keyword TABLE must be used. The first parameter is the table name. The table name is assumed to reside in the Table Path director specified in the XC Rtu or XC Decode setup window. Enter just the name without the path or extension. The second parameter is the sensor value. In this case, the senor value is divided by 100 before being passed in to the rating table.

Example 5:

(ASCII=0)*(X/100) + (ASCII=1)*(X)

This example will evaluate the incoming sensor in two parts like in Example 2 but will base its evaluation on the decoding format. Self-timed messages can be transmitted as ASCII or Binary. Random messages are required to be transmitted as binary. If the ASCII is used as the self-time format, then the number can be converted without any further scaling. However, in binary encoding, the right digits need to be scaled back in. So, if ASCII = 0 (FALSE), indicating 6bit format, then the number will be divided by 100 (incorporate 2 right digits) or if ASCII=1 (TRUE), then do no additional scaling.

Example 6:

DBTable(LOPW.STAGE,X)

This example will retrieve the name stored Rating Table database parameter for the sensor LOPW1.STAGE. The second parameter is the sensor value. The full path and filename must be specified in the Rating Table database parameter. The sensor value will then be passed in to the rating table.

Example 7:

X + SHIFT(LOPW1.STAGE)

This example will retrieve the SHIFT database parameter value for the sensor LOPW1.STAGE and add it to the sensor value X.

Example 8:

X + STN_COEFF(LOPW1,2)

This example will retrieve the COEFFICIENT 2 database parameter value for the station LOPW1 and add it to the sensor value X.

  • Raw List - The Raw list represents a sensor(s) to forward a copy of the sensor value to. Each additional sensor is separated by a comma. NO SPACES after the comma. So if the current value for the sensor is 6.2, then whatever senors are on the Raw List will also receive the value 6.2.

Example 1:

The sensor configured at the data logger is STAGE for station TEST. Also configured as a sensor of TEST is FLOW. The sensor FLOW has an equation associated with it. Thus, when the STAGE sensor value of 6.2 is received and stored, a duplicate value is sent to FLOW. Finally, XC Rtu will apply the equation to the FLOW value of 6.2 and store the computed FLOW value.

  • Right Digits - The Right Digits determines the precision the sensor value. This value should match the Right Digits value configured in the data logger. If the Right Digits value is smaller that the setting in the data logger, the value will be rounded to the Right Digits value in XConnect, thereby losing data. If the Right Digits value is larger than the data logger setting, extra zeros will be added to complete the right digits.

  • Round Off - Round off the time stamp received by current data polls issued by XC Rtu to an specific interval. The modified time stamp cannot be applied to the ASCII Log or EXCEL data storage options. DDE/COM links for $CURRENT, $REALTIME, $ALARM will not have a modified time stamp. For example, if the Round Off is 00:10:00, and the time stamp of the data is 02/14/2004 10:08:32, the rounded time will be 02/14/2004 10::10:00.

  • Data Store Interval - The Data Store Interval parameter allows the user to store a subset of the data retrieved from the RTU. From example, the data is measured and stored every minute in the RTU. The Data Store Interval is 01:00:00. This means that only the data logged at the top of each hour will actually get stored even though all the minute-data will be retrieved.

  • Sensor Decoding Parameters

The Sensor Decoding parameters are only used in a satellite system. These parameters are used by XC Decode to determine the sensor values transmitted. XC Decode uses a positional based decoding scheme to index into the message and decode the data. The sensor decoding parameters act as a set of driving instructions within the data to pick out (stop) at each sensor location. Encoding information must be supplied/described by the data logger manufacturer in the operators' manual. Knowing how the sensor values are encoded and ordered or grouped in the satellite message will allow you to properly configure the sensor encoding parameters for XC Decode. Review the Sensor Decoding topics in the Advanced Topics section.

    • Source - This indicates the source of the satellite message. Transmissions in the data logger can be configured as self-timed or random, as dictated by the satellite agency. The source will be recorded when the data is stored using the database data storage option. S will be recorded in the database from a self-timed message and R will be stored from a random message.

    • Enable - This flag indicates the sensor is active for decoding. XC Decode will not attempt to decode the sensor unless the parameter is checked.

    • Format - This indicates how the data is encoded within the message. The data encoding format will be described by the data logger manufacturer operators' manual. Sutron data loggers are formatted as 6BIT if the user selected BINARY in the data logger or ASCII if SHEF/ASCII is configured in the data logger configuration.

    • Amount - The Amount indicates the number of sensor values XC Decode will try to decode from the satellite messages. This number corresponds to the #TX ITEMS in GOES SETUP MENU in the 8200/8210. For the 9201/XPERT, this number corresponds the NUM VALUES parameter in the Random or Self-Timed telemetry blocks.

    • Bound #1 - Start position in the message after the NESDIS header to look for the Block ID.

    • Bound #2 - Stop position in the message after the NESDIS header to look for the Block ID.

    • Block ID - Unique string to search for that will become a reference starting point to advance to the sensor. There may be a label or unique set of characters that precede the location where the sensor values.

    • Ignore Case - This flags applies to the Block ID text and whether the text must match exactly.

    • Size - Length of sensor in bytes. If BINARY is selected as the data logger transmission format in Sutron data loggers, the Size will always be 3. If SHEF/ASCII is selected in the data logger, set the Size to 0. A 0 value indicates to XC Decode to read characters until the next space. Some ASCII characters may be not formatted to a fixed number of characters.

    • Pos - Byte position in message to start reading characters for sensor value. The Pos value is relative to the first character after the NESDIS header or after the Block ID.

    • Next - Distances in bytes from the Pos position to the next occurrence of the sensor value. If the Amount is > 1, the XC Decode will use Next to advance to the next value of the same sensor.

    • Bit Size - Length of sensor in bits. This parameter serves the same role as Size, if the data is encoded on bit boundaries. Sutron satellite data is encoded on byte boundaries and do not use this value. This value is provided to allow decoding for satellite messages by other data logger manufacturers.

    • Bit Pos - Bit position in messages to start reading characters for sensor value. This parameter serves the same role as Pos, if the data is encoded on bit boundaries. Sutron satellite data is encoded on byte boundaries and do not use this value. This value is provided to allow decoding for satellite messages by other data logger manufacturers.

    • Bit Next - Distances in bits from the Bit Pos position to the next occurrence of the sensor value. If the Amount is > 1, the XC Decode will use Bit Next to advance to the next value of the same sensor. This parameter serves the same role as Bit Next, if the data is encoded on bit boundaries. Sutron satellite data is encoded on byte boundaries and do not use this value. This value is provided to allow decoding for satellite messages by other data logger manufacturers.

    • Interval - This values indicates the difference in measurement times between the multiple sensor values if the Amount is > 1.

    • Offset - Time difference between the measurement time of first decoded sensor value and time of transmission as indicated in the NESDIS header.

    • Round Off - Round off the time stamp calculated by the Interval and Offset to a desired minute or hour. The Round Off should be equal to the measurement time of the sensor.

    • Relative

      • Data - Data values are relative to where offsets from the last the previous decode left off.

      • Time - Times are relative to where the previous decode left off.

      • Pos - Positions are relative to where the previous decode left off.

Sensor Database setup parameters

For the Database data storage option, additional sensor fields are available. Click on the Database Parameters button on the Sensor Setup window to edit sensor database parameters. For a detailed description of the XConnect database schema, go to the XConnect Database Schema topic under Advanced Topics.

  • Name - 12 characters - Same as Sensor parameter on sensor setup window.

  • Enabled - 1 character- Processing enabled for this sensor Y/N.

  • Data Table - 10 characters - Data table number where data are stored, defaults to XC_DATA1.

  • Description - 32 characters - Long descriptive name for sensor.

  • Manufacturer - 20 characters - Manufacturer of sensor.

  • Parameter Code - 12 characters - Code applied to this type of sensor data.

  • Model No. - 20 characters - Model Number of sensor.

  • SHEF PE Code - 7 characters - Standard Hydrologic Exchange Format (SHEF) physical element code.

  • Sensor Threshold Parameters

    • High High Alarm - Number - Valid options are: None, Above, Below.

    • High High Limit - Number - Value representing the high high limit for this sensor.

    • High Alarm - Number - Valid options are: None, Above, Below.

    • High Limit - Number - Value representing the high limit for this sensor.

    • Low Alarm - Number - Valid options are: None, Above, Below.

    • Low Limit - Number - Value representing the low limit for this sensor.

    • Low Low Alarm - Number - Valid options are : None, Above, Below.

    • Low Low Limit - Number - Value representing the low low limit for this sensor.

    • Text Alarm - Number - Valid options are: None, On.

    • Text Limit - 22 characters - Value representing an alarm state if text matches this string.

    • ROC Alarm - Number - Valid options are : None, Above, Below.

    • ROC Interval - Number - Value representing an interval (secs.) over which rate is computed.

    • ROC Limit - Number - Value representing then maximum change rate for data value.

    • No Change Alarm - Number - Valid options are: None, On.

    • No Change Interval - Number - Value representing the maximum time with no change expressed in days and fractions fo days.

    • Deadband - Number - Value representing a delta that will added/subtracted before evaluating the No Change alarm condition.

  • Coefficients

    • Coefficient 1 - Number - General purpose coefficient 1.

    • Coefficient 2 - Number - General purpose coefficient 2.

    • Coefficient 3 - Number - General purpose coefficient 3.

    • Coefficient 4 - Number - General purpose coefficient 4.

    • Coefficient 5 - Number - General purpose coefficient 5.

  • Rating Table

    • Table Name - 255 characters - Full path and filename of the rating table.

    • Shift - Number - General purpose shift number.

    • Offset - Number - General purpose offset number.

  • Generic Sensor Fields

    • Char ID 1 - 12 characters - Alternate parameter code 1.

    • Char ID 2 - 12 characters - Alternate parameter code 2.

    • Number 1 - Number - General purpose number 1.

    • Number 2 - Number - General purpose number 2.

    • String 1 - 20 characters - General purpose string 1.

    • String 2 - 20 characters - General purpose string 2.


Poll group setup parameters

Poll groups are used by XC Rtu to determine how often to request data from the data loggers. Normally, in a conventional system, the system is a "polled" system where the data is requested rather then the data logger just sending the data. Typically, there is one poll group that contains all the stations. Data for all stations will be requested at the same time and interval.

However, there may be occasion where all the stations cannot be polled at the same interval. Sometimes in a system, all the data loggers will not be using the same communication device, such as a radio. In the example of the radio, because of geographic constraints, radio towers cannot be constructed at the remote field station location, so the communication device for these loggers are modems. Thus, modems can be more costly to use (i.e, power consumption and cost of phone calls), it is decided to requested data from these stations only twice a day. Therefore, these modem stations will be in a separated poll group from the radio stations.

Click on the Poll Groups main node [image] or click on an existing poll group number to display the poll group setup window.

Poll group setup parameters

  • Poll Group - Poll group number. The poll group number is automatically incremented when a new poll group is created.

  • Enable - This flag indicates the poll group is active and ready to be scheduled. Poll groups can be created but left "inactive" until a later date.

  • Description - Use this optional field for comments describing the purpose of the poll group.

  • Base Time - Used in conjunction with the Interval, this indicates how often XC Rtu will dispatch the poll group and request for new data. The Base Time represents an offset into the hour. As an example, if the Base Time is 00:05:00 and Interval is 00:30:00, then XC Rtu will dispatch polls for new data 00:05:00, 00:35:00, 01:05:00, 01:35:00...etc.

  • Interval - Used in conjunction with the Base Time, this indicates how often XC Rtu will dispatch the poll group and request for new data. The Base Time represents an offset into the hour. As an example, if the Base Time is 00:05:00 and Interval is 00:30:00, then XC Rtu will dispatch polls for new data 00:05:00, 00:35:00, 01:05:00, 01:35:00...etc.

  • Poll Type - Type of data to be requested from the station. All stations are polled for the same type of data. However, if the None option is selected, then the poll type must be defined individually for each station.

  • None - No data will be polled/requested.

  • Current - Real-time data will requested. Real-time data represents the last measured values. In the 8200/8210/9000, the last measured values is the same as viewing LIVE DATA in the data logger menu setup. Caution, the last measured data may be, when the data request is received, the 40th sample out of 100. In the 9210/XPERT, the last measured data will always be the resultant value from the COMSTAG data block.

  • Date - Logged data will be requested. Logged/time-tagged data is stored in the data logger log with a corresponding time stamp. In the 8200/8210/9000, the time-tagged data is the same as view NEWEST DATA in the data logger menu setup. In the 9210/XPERT, the time-tagged data is the same as the VIEW LOG tab. The date and time of the last data retrieve is stored in the Last Poll field. So, the next poll will start with the Last Poll time.

  • Newest - Logged data will be requested. A Newest data poll retrieves the same data as a Date poll. The difference is who keeps track of the Last Poll time. In the case of a Date poll, XConnect maintains the time field. For a Newest poll, the data logger maintains the time field.

It is recommended to use Date polls. The user has the flexibility/control to adjust this field if data needs to be re-retrieved. The user does not have such access in the data logger in Newest data polls.

  • NoWait - In a normal SSP data request, the message is dispatched and XC Rtu waits for a response. If no response is received before the timeout period, it will retry. After all retries are exhausted, the next SSP message will be dispatched. In NoWait mode, the poll type described in the station setup will be dispatched. Without waiting for a response, it will dispatch the next poll to the next station in the polling list. No retries are performed in the NoWait mode.

  • Clients - An optional list of applications (dependencies) required by XC Decode. Enter the name of the application as it appears on the title bar. As an example, the application executable is EXCEL.EXE, but the application name on the title bar is Microsoft Excel.

As an example, if a custom client application is required to perform additional processing or custom display using the decoded data, adding the application name to the Clients list will ensure that XC Decode will not begin decoding data unless the client (dependent) is running.

  • Bypass Auto Ordering - XC Rtu will try to prioritize the polling queue for efficiency. So, the station list order is not necessarily the order the polls will be dispatched. However, if you would like to maintain the original order, check this parameter.

  • Time Sync - In addition to poll request, a SETCLOCK command can be sent to the data loggers. A SETCLOCK command sends the PC time to the data logger to synchronize the time. The PC time can easily be maintained by many synchronization programs. Creating a poll group that sends a time sync will help maintain time accuracy at the field stations.

    • Yes - This indicates that a SETCLOCK command will be dispatched in addition to the data poll.

    • No - This indicates that only the data poll will be dispatched to the data logger.

    • Only - This indicates that only the SETCLOCK command will be sent, not a data poll.

  • Time Limit - This field is used to help prevent a data logger monopolizing the communication port.

  • Controls

Other control commands can be sent, like the SETCLOCK command, can be in addition to the poll or just alone. A list of commands is described in the Technical Reference help file.

    • Send Control Command Only - Normally, additional control command(s) are sent in addition to the poll. However, checking this box will indicate to XC Rtu to only send the control command.

    • Command - Allows a Control command to be sent to the data logger, i.e., GETTAG,%p,sensor --> GETTAG,%p,AT will substitute the Station name for %p and retrieve sensor AT (see Technical Ref for list of command).

  • Stations in Poll Group - This list represents the station that will be polled in this poll group.

  • Available Stations - This list displays of all the XConnect stations.


Communication port parameters

Communication port setup parameters

The COM port setup window represents the parameters used to configure a communication port in XConnect. Parameters inform the XConnect module, XC Rtu, how to initiate the communications device and the duration of timeouts.

Click on the Communications Ports main node [image] or click on an existing COM port name to display the COM port setup window.

COM port setup parameters

  • Baud Rate - Communications rate of device. Options are: 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200.

  • Port - For direct and radio types, select port number communication device is attached to. Select COM0 if com port type is Virtual.

  • Modem - For modem types, select the desired modem from the modem list.

  • Sutron Standard Protocol (SSP)

    • SSP Retries - After connection, this value indicates number of times XC Rtu will re-send the SSP message, if a response is not received.

    • RX Timeout (s) - Seconds to wait before timing out waiting for a response for the primary com port. This is the maximum amount of time XC Rtu will wait for an acknowledgement (ACK) after it has sent an SSP message.

The RX timeout applies to the following commands: SEND MAIL, CURRENT data polls, GET STATUS, GET VALUE, SEND VALUE, GET RDI, SEND RDI.

Example 1:

When XC Rtu sends a mail message, an ACK is expected from the data logger.

Example 2:

When XC Rtu sends a Current data poll, a response is expected from the data logger before the TX Timeout expires before trying again.

    • TX Timeout (s) - Seconds to wait before timing out sending a message for the primary com port. This is the maximum amount of time XC Rtu will wait for a response from the data logger.

The TX timeout applies to the following commands: DATE/MANUAL data polls, GET SETUP, SEND SETUP.

Example 1:

When XC Rtu sends a Date poll, the response can be in multiple SSP messages. After the receipt of each SSP message, XC Rtu sends an ACK to the data logger and then the data logger will send the next packet. If the next packet is not sent within the TX Timeout period, XC Rtu will retry.

  • Reply Delay (s) - Delay in seconds before sending message. When using radio, the reply delay is first used then the carrier on delay will be used.

  • Line-of-Site (LOS)

    • Carrier On Delay (s) - Time in seconds to key the radio before sending the SSP message. For analog radios, keying the radio acts to start the radio transmitter. Some times, additional time is required for the transmitter to rise from quiescent to full power mode (synthesizer to lock on). In these cases, it is necessary to adjust the time to key the radio to ensure that full package is received. Digital radios normally key upon receipt of data (because they normally buffer data). Analog radios are slightly different, hence it is necessary to raise the carrier long enough to unsure proper transmission of data.

    • Carrier Off Delay (s) - Time in seconds to wait before unkeying the radio after sending the SSP message. In the cases for the carrier on delay parameter, a pause may be necessary before unekying the radio transmitter to ensure proper transmission of data.

  • Virtual

Virtual connections will only send IP messages using UDP or IP protocols.

    • TX IP Port - IP port to send SSP messages.

    • RX IP Port - IP port to receive SSP messages.

    • Protocol - IP Protocol. Use choices are UDP or TCP.

  • Telephone Modem

    • Rings to answer - XC Rtu will answer an incoming telephone call on this number of rings. Setting the value to 0 will disable an incoming calls

    • Dial Retries - Number of times to re-dial the phone number if connection is unsuccessful (i.e., BUSY, NO CARRIER, NO DIALTONE, etc...).

    • Dial Timeout (s) - Seconds to wait after dialing to negotiate handshaking.

    • Touch Tone - This parameter is checked by default. Un-check if touch-tone is unavailable.

    • Init String - Extra Hayes commands to send during modem initialization.

    • Hangup String - Extra Hayes commands to send during modem hang up.

  • DSR DRGS

    • IP Port - IP port of the DSR DRGS. Ensure the port number matches the port number set in the DSR DRGS configuration software. Go to the Properties main menu of the DCP Monitor software provided by the DSR DRGS manufacturer. Select the General option from the Properties main menu. Verify the Port number parameter.

  • Advanced Port Settings

    • Control Line - Sets the control line to be used in detecting connection or carrier. Valid options are: Default, None, CTS (Clear To Send), DSR (Data Send Ready), CD (Carrier Detect). If set to Default, None will be used for Direct and Virtual communication types and CD will be used for Radio and Modems.

    • Connect Timeout - Seconds of inactivity to hold a manual connection before hanging up.

    • Busy Timeout - Seconds to wait for a port to become available when sending a message.

    • Auto Timeout - Seconds of inactivity to hold an automatic connection before hanging up.

    • Connect Delay - Seconds to pause after a connection. Some modems will hang up without a delay.

    • Max Parsers - Limits the number of messages sent simultaneously when No Wait is enabled.

    • SW Handshake - Enables SW (software) handshaking. This indicates that a ^Q (DC1) will be sent and a ACK is expected as a response to indicate a good connection. After this handshaking is established, the SSP message will be sent.

    • HW Handshake - Enables HW (hardware) handshaking. This indicates that RTS/CTS (Ready To Send/Clear To Send) will be used to negotiate a connections. This is required for today's high speed modems.

    • No Wait - Allows multiple SSP messages to be sent simultaneously without waiting for a response. Normally, XC Rtu will send a SSP message and wait for a response before sending the next SSP message.

    • Auto Baud - This check box will cause the baud rate to be switch to that returned by the modem's CONNECT response.


Data storage parameters

The lower case letters "yy", "yyyy", "mm, "dd", "hh", "mi" can be included in the name to instruct the software to created separate minute, hourly, daily, monthly, or yearly files. Optionally, "#nn: can be added to specify that a new file should be created every nn minutes (when using "mi") or hours (when using "hh"), or days (all other). The "#nn" can appear anywhere in the string, where nn must be two digits with leading zeros, if necessary.

The dating of raw files is important for easy backup, purging or distribution of raw data; and reprocessing of raw data through XC Decode. If the files are allowed to grow too large, these processes will become more difficult or require excessive time to perform. The default setting of yyyymmdd.RAW creates a separate file each day.

Example 1:

MYDATdd.RAW would create the file MYDAT01.RAW on the first day of the month, MYDAT02.RAW on the second day, and so on until the next month MYDAT01 would be used again. NESmm.RAW would create the file NES01.RAW to contain all the data for January, NES02.RAW to contain all the data for February, and so on until the next month.

Example 2:

yymmddhh.RAW#02 would create a new output file every 2 hours. If the "#02" was left off, a new file would be created every hour. As well, mmddhhmi.RAW#15 would create a new output file every 15 minutes.

The lower case letters "yy", "yyyy", "mm, "dd", "hh", "mi" can be included in the name to instruct the software to created separate minute, hourly, daily, monthly, or yearly files. Optionally, "#nn: can be added to specify that a new file should be created every nn minutes (when using "mi") or hours (when using "hh"), or days (all other). The "#nn" can appear anywhere in the string, where nn must be two digits with leading zeros, if necessary.

The dating of raw files is important for easy backup, purging or distribution of raw data; and reprocessing of raw data through XC Decode. If the files are allowed to grow too large, these processes will become more difficult or require excessive time to perform. The default setting of yyyymmdd.RAW creates a separate file each day.

Example 1:

MYDATdd.RAW would create the file MYDAT01.RAW on the first day of the month, MYDAT02.RAW on the second day, and so on until the next month MYDAT01 would be used again. NESmm.RAW would create the file NES01.RAW to contain all the data for January, NES02.RAW to contain all the data for February, and so on until the next month.

Example 2:

yymmddhh.RAW#02 would create a new output file every 2 hours. If the "#02" was left off, a new file would be created every hour. As well, mmddhhmi.RAW#15 would create a new output file every 15 minutes.

Data storage setup parameters

The Data Storage setup window represents the parameters used to configure a data storage option in XConnect. Parameters inform the XConnect modules, XC Rtu or XC Decode, how and where to stored the processed sensor values.

Click on the Data Storage Systems main node [image] or click on an existing station name to display the Data Storage setup window.

Data Storage setup parameter

  • Data Storage Type - This read-only parameters indicates the data storage option selected on the System Init window. Return to the System Init window to change the storage option.

  • Data Storage Limit - Number of days of data to maintain. For all storage options other than database, XConnect will maintain the data storage limit and delete the data outside the range.

  • PcBase2 Binary File Settings

PcBase2 binary files are proprietary, fixed-interval files. Each file has a header that contains the description, start date, end date, base time, interval and sensor list. The data is stored as a contiguous series of binary values. There are no individual time stamps recorded with each value. The correct value for a desired time is calculated by the start date, end date, interval and sensor list parameters. Based on the computation using these parameters, XConnect know how far to index into the file to retrieve the sensor value.

Example: If data retrieved by a current data poll at 02/12/2003 10:03:14, and the fixed interval of the file is 00:15:00, then the data value will be stored at the 02/12/2003 10:00:00.

    • File Path - Directory location of Pcbase2 binary files.

    • Files - List of PcBase2 binary files. Only the file names are listed. The extensions are .DAT and their location is described by the File Path parameter.

    • Description - Optional description of binary data file.

    • Start Date - Start date if data. Data retrieved from data loggers that is before the Start Date will not be saved.

    • End Date - Read-only parameter indicating the date and time of the last data stored.

    • Base Time - Offset from the hour when data will be stored.

    • Interval - Interval data will be forced to be stored at. This should match the measurement interval of the sensor in the data logger. If the sensor is being measured every minute, the Interval should be set at 00:01:00 also. For 8200/8210/9000 data loggers, there is one measurement interval for all sensors. The 9210/XPERT allow the user to configure a different measurement interval for each sensor.

    • Sensors in Binary File - This list represents the sensors stored in this data file.

    • Available Stations - This pull-down list box displays all the stations configured in XConnect and reflects Stations node.

    • Available Sensors - For the station selected in the Available Stations parameter, this list box displays the sensors associated with that station.

  • XConnect Database Settings

XConnect database schema consists of a set of 4 “management” tables and a set of 4 "data" tables. The XConnect tables are designed to provide a great deal of flexibility in 1) Naming of stations and data parameters, 2) Grouping data through such attributes as river basin or political boundaries, and 3) Managing the size of data tables so that performance is maximized.

The XConnect design is not dependent on a specific database or database type. This allows XConnect to use virtually any relational database.

    • Data Source - Select the ODBC data source name from the pull-down list box. If your data source does not appear, got to the Data Sources (ODBC) applet to configure your data source. Or, consult your network administrator to assist in the data source configuration.

    • User Name - Enter the login user name to the data source.

    • Password - Enter the login password to the data source.

  • ASCII Log/EXCEL/XML File Settings

The ASCII/EXCEL/XML are all file based storage options. No plotting or display is currently available. The purpose of these data storage options, in many cases, is to use it as input for an established data storage system. XConnect serves as the data provider for a data storage and data display system already in place. The ASCII log and EXCEL storage options follow the same format. The XML format is also very straight forward.

    • File Path - Directory location of ASCII Logger, EXCEL, or XML files.

    • File Name - The naming pattern of the output files. The pattern contained in this field determines the name of the file which XC Rtu or XC Decode will create and/or append to data is received and processed. Tips on file naming convention.

    • Station Prefix - Check this box if you would like the station name to be the first part of the file name generated by the File Name parameter..

    • Station Suffix - Check this box if you would like the station name to be the appended to the file name generated by the File Name parameter.


XC Rtu setup window

The XC Rtu setup window represents the parameters used to configure the XC Rtu module. Recall, the role of XC Rtu within an XConnect data collection system is to communicate to Sutron dataloggers using Sutron Standard Protocol (SSP). If a modem, radio, line driver, or serial cable is connected to the Sutron datalogger, this is considered a conventional system and SSP is used in the primary language used. XC Rtu can initiate data requests via SSP and is always monitoring communication ports for SSP messages transmitted by Sutron data loggers. XC Rtu also applies any user-defined equations or lookup tables to incoming data and then stores data to the user-selected data storage option.

These parameters can also be modified in the XC Rtu module by accessing the Edit Setup parameters option ( [image]).

Expand the Conventional Systems main node [image]. Then click on the XC Rtu node [image] to open the XC Rtu setup window.

XC Rtu Setup Parameters

  • Master ID - SSP Unit ID of the base station computer. Just as each data logger has a name (Unit ID), so does the base station.

  • Listen ID - List of SSP Unit IDs to listen to and to parse messages no but not respond or ACK to. XC Rtu is listening to the SSP conversations or another XConnect/XC Rtu system but is not interacting. This is the same as having 2 telephones in a house. If you picked up the second line, you would be listening (or eavesdropping) on the conversation initiated by the person on the first line, but not speaking or engaging in the conversation.

  • Listen Update - Check this flag to have XC Rtu update the Last Poll date with the last data received from the Listen IDs.

  • Re-Poll Limit - For missing data, the parameter represents how much data to re-poll when a sensor is missing from the data. So, if the current date and time minus then date and time of the last received data is less then the Re-Poll limit time, data will be re-polled.

  • Setup Path - Location of setup files. The directory location is the default path for the Setup File parameter on the station setup window.

  • Table Path - Location of rating/lookup tables. The table files have .TBL extensions are and are used in sensor equations.

  • Use 24 hour - This flag is normally not checked. If the user would prefer the time of 00:00:00 to be stored as 24:00:00, then check this flag. This will shift the day from 00:00:00 - 23:59:59 to 00:00:01 - 24:00:00.

  • Save real-time data items - XC Rtu will store all data values it keeps in its internal real-time database. The real-time database is used by clients requesting DDE or COM sensor data. If using Wonderware or other HMIs, saving the data items and loading them on start-up will initialize all DDE points used on the HMI. If not used client software, this flag should remain unchecked.

  • Store Quality - As SSP messages are dispatched and received, XC Rtu can log the success or failure of the SSP message and the type of error encountered. This SSP quality information can be optionally stored. For a database, the information is stored in the XC_RTUQC data tables. This allows operators to generate reports to determine station or com port statistics.

  • Auto Topic Settings

    • Auto Poll - How often automatic DDE data points will be polled, 0=Disable.

    • Auto Update - How quickly automatic DDE data points are updated, 0=Disable.


XC Decode setup window

The XC Decode setup window represents the parameters used to configure The XC Decode module. Recall, XC Decode is used in satellite systems (data loggers using GOES or SATLINK transmitters) - one way communication systems. The role of XC Decode within an XConnect data collection system is to read and decode satellite DCP messages stored in ASCII files by XC Mux. Sensor decoding parameters are configured by the user in the Sensor setup window. XC Decode then uses these parameters like a "road map" to the sensors' position in the satellite message. XC Decode applies any user-defined equations or lookup tables on data and then stores data to user selected data store option.

These parameters can also be modified in the XC Decode module by accessing the Edit Setup parameters option ( [image]).

Expand the Satellite Systems main node [image]. Then click on the XC Decode node [image] to open the XC Decode setup window.

XC Decode Setup Parameters

  • Auto Decode Path - The directory(s) to read the raw NESDIS files for new satellite messages. The raw files are created by XC Mux.

  • Auto Decode File - The wildcard pattern (*.RAW) of the raw NESDIS files to read. XC Decode will search for files matching the Auto Decode file in the Auto Decode Path.

  • Decode to Local Time - XC Decode will automatically subtract the GMT offset based on Windows Regional Settings from satellite message time to store the data in the data storage option at local time.

  • Custom GMT Offset - Do not use Windows Regional Settings GMT offset, but use will enter will a custom offset to be used by XC Decode.

  • GMT/UTC (Hours) - Number of hours local time is ahead of Greenwich Mean Time when Custom GMT offset is checked. Prior to data storage, XC Decode will subtract the GMT from the message time. Value can be a positive or negative time difference.

  • Auto Base Time - Used in conjunction with the Auto Interval, this indicates how often XC Decode will check the Auto Decode Path for new messages in raw files. Auto Base Time represents an offset into the hour. As an example, if the Auto Base Time is 00:05:00 and the Auto Interval is 00:30:00, then XC Decode will check for new messages at 00:05:00, 00:35:00, 01:05:00, 01:35:00...etc.

  • Auto Interval - Used in conjunction with the Auto Base Time, this indicates how often XC Decode will check the Auto Decode Path for new messages in raw files. Auto Base Time represents an offset into the hour. As an example, if the Auto Base Time is 00:05:00 and the Auto Interval is 00:30:00, then XC Decode will check for new messages at 00:05:00, 00:35:00, 01:05:00, 01:35:00...etc.

  • Table Path - Location of rating/lookup tables. The table files have .TBL extensions are and are used in sensor equations.

  • Run Parameters - An optional list of programs to run when the XC Decode program is started. These programs will be started before XC Decodes begins processing messages. If the application does not reside in the XConnect home directory, list the file path with the executable name (i.e., c:\myapp\myapp.exe).

As an example, a custom client program may used to display decoded data in a specific layout. To ensure the client program is automatically running when XC Decode starts, add the client program executable name to the Run parameter list.

  • Clients - An optional list of applications (dependencies) required by XC Decode. Enter the name of the application as it appears on the title bar. As an example, the application executable is EXCEL.EXE, but the application name on the title bar is Microsoft Excel.

As an example, if a custom client application is required to perform additional processing or custom display using the decoded data, adding the application name to the Clients list will ensure that XC Decode will not begin decoding data unless the client (dependent) is running.

  • Store Quality - As satellite messages are decoded, the header portion of the message includes transmission quality information. This quality information can be optionally stored. For a database, the information is stored in the XC_QUALITY data tables. For all other data storage options, the information is stored in ASCII log files.

  • Quality File Path - For data storage options other than databases (Oracle, Access or SQL Server), quality information is stored in ASCII log files. The quality log files are stored in the Quality File path directory.

  • Quality File - This is field indicates the file name pattern of the log files. This parameter cannot be edited. These files will be created on a daily basis (QLyymmdd.log)

  • Save real-time data items - XC Decode will store all data values it keeps in its internal real-time database. The real-time database is used by clients requesting DDE or COM sensor data. If using Wonderware or other HMIs, saving the data items and loading them on start-up will initialize all DDE points used on the HMI. If not used client software, this flag should remain unchecked.

XC Decode Channel Setup Parameters

  • Channel - Satellite channel messages are received on. The Channel should always be 3 digits long, 000 -199 and is assigned to you with the satellite id.

  • Format - This indicates what type of satellite messages will be received on the channel. For database storage options, the source of the data (Self-Timed or Random) will be included in the data record.

Note: After adding or making changes to any of the channel, click on either the Add button (for a new channel) or Update button (for an existing channel).


XC Mux setup parameters

The lower case letters "yy", "yyyy", "mm, "dd", "hh", "mi" can be included in the name to instruct the software to created separate minute, hourly, daily, monthly, or yearly files. Optionally, "#nn: can be added to specify that a new file should be created every nn minutes (when using "mi") or hours (when using "hh"), or days (all other). The "#nn" can appear anywhere in the string, where nn must be two digits with leading zeros, if necessary.

The dating of raw files is important for easy backup, purging or distribution of raw data; and reprocessing of raw data through XC Decode. If the files are allowed to grow too large, these processes will become more difficult or require excessive time to perform. The default setting of yyyymmdd.RAW creates a separate file each day.

Example 1:

MYDATdd.RAW would create the file MYDAT01.RAW on the first day of the month, MYDAT02.RAW on the second day, and so on until the next month MYDAT01 would be used again. NESmm.RAW would create the file NES01.RAW to contain all the data for January, NES02.RAW to contain all the data for February, and so on until the next month.

Example 2:

yymmddhh.RAW#02 would create a new output file every 2 hours. If the "#02" was left off, a new file would be created every hour. As well, mmddhhmi.RAW#15 would create a new output file every 15 minutes.

Using the raw file naming convention, files will be created daily, hourly or as the user-defines. Thus, when the day ends or the hour is over, the current raw file will be closed and a new one opened.

Upon closing the current raw file, a copy of the file will be made and moved to each Raw File Copy subdirectory.

XC Mux setup window

The XC Mux setup window represents the parameters used to configure The XC Mux module. Recall, the role of XC Mux within an XConnect data collection system is to retrieve DCP messages from a Sutron receive site multiplexor/digitial direct readout ground station (DDRGS) and store them in ASCII files. XC Mux interfaces with the Sutron receive site (DDRGS) via a standard serial port connection.

These parameters can also be modified in the XC Mux module by accessing the Edit Setup parameters option ( [image]).

Expand the Satellite Systems main node [image]. Then click on the XC Mux node [image] to open the XC Mux setup window.

XC Mux Setup Parameters

  • Raw Path - The directory to store the raw NESDIS files as the satellite messages are received by the DDRGS hardware.

  • Raw File - The naming pattern of the raw data output files. The pattern contained in this field determines the name of the file which XC Mux will create and/or append to as messages are received from the multiplexor. Tips on raw file name convention [image] .

  • Com Port - The PC port number to which the receive site multiplexor is physically connected. (eg, COM1...COM9).

  • DDRGS Type - This indicates whether the receive site multiplexor is a DDRGS or a HDR DDRGS. If your receive site can receive satellite messages at 100, 300 and 1200 baud, select HDR DDRGS.

  • Run Parameters - An optional list of programs to run when the XC Mux program is started. These programs will be started before XC Mux begins processing messages. If the application does not reside in the XConnect home directory, list the file path with the executable name (i.e., c:\myapp\myapp.exe).

As an example, a custom client program may used to display decode satellite messages instead of XC Decode. To ensure the client program is automatically running when XC Daps starts, add the client program executable name to the Run parameter list.

  • IP Address - This parameter is used only for the DSR DRGS. IP address of the DSR DRGS computer. Ensure the IP address matches the port number set in the DSR DRGS configuration software. Go to the Properties main menu of the DCP Monitor software provided by the DSR DRGS manufacturer. Select the General option from the Properties main menu. Verify the IP address parameter.

  • Force Time Sync - Check this option to force the time synchronization between the PC time and the DDRGS time. XC Mux synchronizes the DDRGS time with the PC hourly. If the time difference between the DDRGS and the PC is greater than 2 seconds, XC Mux will send a time command to the DDRGS.

  • Add ETX as EOM - Used with DSR DRGS, if checked, three ETX characters will be appended to each raw messages when written to the raw files. This aids as a delimiter marker for the end of a raw message for other decoding programs.

  • DDRGS Time Offset - Hourly XC Mux will check the time of the DDRGS. If it has differed from the PC clock, a time correction will be sent. It is important to keep the PC clock synchronized. The DDRGS Time Offset will be subtracted from the PC time before being sent to the DDRGS.

  • Listen Mode Only - If two PCs are connected to the same receive site multiplexor, then only one can be considered the primary controlling PC. The other PC, secondary, will have XC Mux configured to Listen mode, receiving and storing messages, but not controlling the DDRGS.

  • Save real-time data items - XC Decode will store all data values it keeps in its internal real-time database. The real-time database is used by clients requesting DDE or COM sensor data. If using Wonderware or other HMIs, saving the data items and loading them on start-up will initialize all DDE points used on the HMI. If not used client software, this flag should remain unchecked.

  • No NESDIS Header - Check this flag if you would prefer to strip off the NESDIS header (first 37 characters) from the satellite message before storing to the raw file. This flag is rarely used. This may be useful if the transmitted message is a complete formatted text message (i.e. WMO message) that just needs to be stored to disk.

  • Raw File Copies - Alternate copies of the raw files will be created. Alternate copies will be created in subdirectories of the Raw Path named Copy1, Copy2, Copy3...etc. The alternate copy is created after the raw file is closed [image] .

XC Mux Demod Setup Parameters

  • Demod - Each demodulator in the receive site will must have a unique id number. For the HDR DDRGS the range of demods is 00-15. For all other DDRGS models, the range of demods is 00-07. Enter the number for the demod whose settings are to be added or updated.

  • Channel - This indicates which channel the demod is set to. The Channel should always be 3 digits long, 000 -199 and is assigned to you with the satellite id.

  • Location - Select from the drop-down the geographic location for the satellite. E should be used for GOES East, W for GOES West, and C for GOES Central.

  • Baud - Select from the drop-down list the data rate (bps) for this demod (used for HDR DDRGS only).

  • Threshold - Saturation threshold for each demod (used for HDR DDRGS only). Value is as a sensitivity or noise threshold.

Typical threshold settings for the DDRGS are 40 dB for 100 baud channels and 60 dB for 300 and 1200 baud channels.

Note: After adding or making changes to any of the demod fields, click on either the Add button (for a new demod) or Update button (for an existing demod).


XC Daps setup parameters

The lower case letters "yy", "yyyy", "mm, "dd", "hh", "mi" can be included in the name to instruct the software to created separate minute, hourly, daily, monthly, or yearly files. Optionally, "#nn: can be added to specify that a new file should be created every nn minutes (when using "mi") or hours (when using "hh"), or days (all other). The "#nn" can appear anywhere in the string, where nn must be two digits with leading zeros, if necessary.

The dating of raw files is important for easy backup, purging or distribution of raw data; and reprocessing of raw data through XC Decode. If the files are allowed to grow too large, these processes will become more difficult or require excessive time to perform. The default setting of yyyymmdd.RAW creates a separate file each day.

Example 1:

MYDATdd.RAW would create the file MYDAT01.RAW on the first day of the month, MYDAT02.RAW on the second day, and so on until the next month MYDAT01 would be used again. NESmm.RAW would create the file NES01.RAW to contain all the data for January, NES02.RAW to contain all the data for February, and so on until the next month.

Example 2:

yymmddhh.RAW#02 would create a new output file every 2 hours. If the "#02" was left off, a new file would be created every hour. As well, mmddhhmi.RAW#15 would create a new output file every 15 minutes.

XC Daps setup window

The XC Daps setup window represents the parameters used to configure The XC Daps module. Recall, the role of XC Daps within an XConnect data collection system is to retrieve DCP messages from the NOAA DAPS database. XC Daps starts a telnet session, logs into the DAPS database and downloads satellite messages and stores them in ASCII files. XC Daps is used as backup method of satellite message retrieval to a Sutron receive site (DDRGS).

DAPS is the DCS (Data Collection System) Automated Processing System maintained through NOAA which disseminates all GOES satellite messages. DAPS will maintain all satellite messages transmitted by all DCPs (data collection platforms/data loggers) up to 72 hours. After data is disseminated and stored, it is available to all DAPS users. DAPS monitors the quality of all DCP data. It compiles real-time statistics over the short and long term for all data. Using the DAPS commands, users can view and download satellite data.

DAPS issues abnormal response message(s) whenever a DCP operates improperly. DAPS can detect timing errors, wrong channel errors, address error, unexpected message errors, missing message errors and incomplete PDT (platform description table) errors. If a DCP message is received with any of these problems, the DAPS will issue adn ASCII text message describing the event. This will be part of the messages stored for the satellite id along with the transmitted messages.

DAPS can be accessed via the internet by http://dcs.noaa.gov.

These parameters can also be modified in the XC Daps module by accessing the Edit Setup parameters option ( [image]).

Expand the Satellite Systems main node [image]. Then click on the XC Daps node [image] to open the XC Daps setup window.

XC Daps Setup Parameters

  • Telnet Settings

    • IP Address - IP address of DAPS database. Consult NOAA DAPS web-site for any changes in DAPS telnet ip address.

    • Retries - Number of times to retry it telnet connection to IP address fails.

    • Retry Wait - Seconds to wait between retries.

  • DAPS Login Settings

    • User name - DAPS user name. User name is provide by DAPS when application is submitted for satellite ids.

    • User password - DAPS user password. Login password into the DAPS database. This is also provided by DAPS.

    • Firewall password - DAPS firewall password. This is provided by DAPS.

  • Message Types

    • Default - Download all messages in DAPS database for satellite id.

    • Good (G) - Download good DCP messages.

    • Address Errors (A) - Download messages issued by DAPS with address errors. Address errors can sometimes be correctable by DAPS.

    • Missing (M) - Download messages issued by DAPS flagging missing messages.

    • Unexpected (U) - Download messages issued by DAPS flagging unexpected messages.

    • Wrong Channel (W) - Download messages issued by DAPS flagging messages received on the wrong channel.

    • Time Error (T) - Download messages issued by DAPS flagging transmit time errors.

    • PDT Incomplete (P) - Download messages issued by DAPS flagging incomplete PDT records.

    • Multiple Channels (D) - Download messages issued by DAPS flagging messages received on multiple channels.

    • Parity Errors (?) - Download DCP messages with parity errors.

  • Download Settings

    • Base Time - Used in conjunction with the Interval, this indicates how often XC Daps will login to the DAPS database and download satellite messages into raw files. Base Time represents an offset into the hour. As an example, if the Base Time is 00:05:00 and Interval is 00:30:00, then XC Dapse will check for messages at 00:05:00, 00:35:00, 01:05:00, 01:35:00...etc.

    • Interval - Used in conjunction with the Base Time, this indicates how often XC Daps will login to the DAPS database and download satellite messages into raw files. Base Time represents an offset into the hour. As an example, if the Base Time is 00:05:00 and Auto Interval is 00:30:00, then XC Daps will check for messages at 00:05:00, 00:35:00, 01:05:00, 01:35:00...etc.

    • GMT/UTC - Number of hours local time is ahead of Greenwich Mean Time. Prior to data storage, XC Decode will subtract the GMT from the message time. Value can be a positive or negative time difference.

    • Raw Path - The directory to store the raw NESDIS files as the satellite messages are received by the DDRGS hardware.

    • Raw File - The naming pattern of the raw data output files. The pattern contained in this field determines the name of the file which XC Mux will create and/or append to as messages are received from the multiplexor. Tips on raw file naming convention.

    • Last Download - Timestamp of last satellite message downloaded by XC Daps. XC DAPS will update this field each time a messages from a satellite id are stored. XC Daps will track the last download times from all the satellite ids and save the earliest of all the download times as the Last Download time. The Last Download time will be the start time for the next download cycle. The time is GMT like the DAPS database.

    • No NESDIS Header - Check this flag if you would prefer to strip off the NESDIS header (first 37 characters) from the satellite message before storing to the raw file. This flag is rarely used. This may be useful if the transmitted message is a complete formatted text message (i.e. WMO message) that just needs to be stored to disk.

    • Run - An optional list of programs to run when the XC Daps program is started. These programs will be started before XC Daps begins processing messages. If the application does not reside in the XConnect home directory, list the file path with the executable name (i.e., c:\myapp\myapp.exe).

As an example, a custom client program may used to display decode satellite messages instead of XC Decode. To ensure the client program is automatically running when XC Daps starts, add the client program executable name to the Run parameter list.


Users setup window

The Users setup window represents the parameters used to configure a user in XConnect. Parameters inform the primary XConnect modules, XC Setup, XC Desktop, XC Rtu, XC Decode, and XC Mux, XC DataView, the user logged and their privileges in the XConnect system.

Click on the Users main node [image] or click on an existing user name to display the Users setup window.

Users setup parameters

  • User Name - Name of XConnect user.

  • Description - Text describing user.

  • Password - Login password of user.

  • Confirm Password - Re-type password to verify characters in Password parameter.

  • Access - Valid options are: NONE. FULL, READ-ONLY, CUSTOM.

    • NONE - User has no privileges to start XC Desktop and has no privileges to open any sub-windows or access any control options in the primary XConnect modules.

    • FULL - User has all privileges to start XC Desktop and has full privileges to open any sub-windows or access any control options in the primary XConnect modules.

    • READ-ONLY - User has privileges to view but not modify XC Desktop setup windows. As well, user can view any sub-windows, but cannot modify sub-window parameters or access any control options in the primary XConnect modules.

    • CUSTOM - User has privileges to only specific setup windows in XC Desktop and sub-windows in the primary XConnect modules.

  • Custom Access Options

    • Station Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the Station setup window only.

    • Sensor Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the Sensor setup window only.

    • Com Port Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the Com port setup window only.

    • Poll Group Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the Poll group setup window only.

    • Data Storage Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the Data storage setup window only.

    • XC Rtu Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the XC Rtu setup window in XC Desktop and the Edit Setup parameters window in XC Rtu.

    • XC Decode Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the XC Decode setup window in XC Decode and the Edit Setup parameters window in XC Decode.

    • XC Mux Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the XC Mux setup window in XC Desktop and the Edit Setup parameters window in XC Mux.

    • XC Daps Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the XC Daps setup window in XC Desktop and the Edit Setup parameters window in XC Daps..

    • System Init Setup - Valid options are: NONE. FULL, READ-ONLY, CUSTOM. This describes access for the System Init setup window only.


Configuring a Data Source (ODBC)

If the user selects a database (Access, Oracle or SQL Server) as the data storage type, the System Data Source must be configured first before completing the XConnect data storage parameters in XC Desktop.

If the Data Source has not been configured:

  1. Close XC Desktop.

  2. Follow the steps to configure the Data Source shown below.

  3. Re-open XC Desktop to finish the Data Storage setup.

Configuring Access (using Windows 2000/XP)

  1. Select Start|Settings Control Panel. Select the Administrative Tools control applet.

  2. In the Administrative Tools applet, double-click the Data Sources (ODBC) icon.

  3. In the System DSN tab of ODBC Data Source Administrator window, select the Add button to add a new data source.

  4. In the Create Data Source window, select the Microsoft Access driver from the list of drivers. Select Finish button.

  5. The ODBC Microsoft Access Setup window will appear.

  6. Type in a name to represent the data source and a description, if desired.

  7. Click on the Select button to select the desired Microsoft Access database file (.mdb). An Access file (.mdb) for XConnect is installed in the XConnect installation directory.

  8. Click OK after selecting the appropriate file. The name of the file will be displayed on the ODBC Microsoft Access setup window.

  9. Click OK to complete the ODBC Microsoft Access setup. Notice the addition of the data source on the System DSN tab.

  10. The data source has been setup. Re-Start XC Desktop and select the data source from the Data Source pull-down list box on the Data Storage System Setup window.

A Microsoft Access database is very convenient for the small system user but can be inefficient. On a regular schedule the database should be defragmented by compacting it. Compacting a Microsoft Access database will:

  • Reorganize a table's records so they reside in adjacent database pages, ordered on the table's primary key. This will improve the performance of sequential scans of a table's records, as the minimum number of database pages will have to be read to retrieve all of the records.

  • Reclaim unused space created by object/record deletions. When objects and/or records are deleted from a database, the space they occupied is marked as being available. However, the size of the database never shrinks unless the database is compacted.

  • Reset Counter fields so the next value allocated will be 1 more than the last undeleted Counter record.

  • Regenerate the table statistics used in the query optimization process. These statistics can become out of date over time, typically due to transactions being rolled back or turning off your workstation without closing the Microsoft Access database as the statistics are cached in memory.

In order to be able to compact a database, the following must be valid:

  • The user of Microsoft Access who performs the compaction must have Modify Design permission for all tables in the database.

  • There must be sufficient disk space on the file server for both the original and compacted versions of the database, even if the database is being compacted using the same filename, as only when the compaction has been successful is the compacted database renamed as the original database.

  • No user currently has the database open. When a database is compacted, it has to be opened exclusively to prevent any users from accessing and modifying the database while the compaction is in progress. If the database is currently open by one or more users, the compaction will be unable to proceed.

TIP: If your hard disk is badly fragmented, it is a good idea to defragment it before compacting the database. This allows for the data to be written not only sequentially in the database, but also sequentially on disk should space allow.

Configuring SQL Server

SQL Server offers enterprise-level database engine with scalability and availability. The database engine protects data integrity while minimizing the overhead of managing thousands of users concurrently modifying the database. It provides XConnect unlimited data space that only limited by available storage. It is perfect to accommodate ever increasing data gathered by XConnect and data mining.

In order to use XConnect SQL Server option, the SQL Server database must be prepared and properly configured. Several SQLServer versions are supported:

  • SQL Server 2000

  • SQL Server 7.0 (*)

  • SQL Server 6.5 (*)

  • MSDE 2000

Note: The scripts for 7.0 and 6.5 may need modification because the script supplied are ONLY tested on SQL Server 2000 and MSDE 2000.

Scripts supplied with XConnect will create its own database, users, tables, views and indices to store its needed information. Configure the ODBC data source with SQL authentication on Q1-b.

Configuring Oracle

As with SQL Server, an Oracle database is very powerful and scalable. The database administrator will be responsible for installing and configuring the database on a separate network server.

Additionally, security settings will need to be setup for all users logging into the database. Verify XConnect the user can read/execute the Oracle ODBC driver, typically the "SQORA32.DLL". In Explorer, go to Oracle installation folder. Right click on ORA816 and choose Properties. Please contact your network or database administrator to configure the data source for Oracle or SQL Server.


Connecting to a remote XC Setup

Normally, XC Desktop will connect to the XC Setup running on the same computer. Since XConnect modules are automation servers, connections can be made remotely over a network. In many cases, the XConnect base station computer that is controlling communications is in a separate office or building than the users. In this situation, the users can run XC Desktop on his/her local machine and connect over the network to the XC Setup running on the XConnect base station.

To connect to a remote XC Setup:

  1. From the main menu, select File|Connect or click on the [image] to select a computer node on the network.

  2. After selecting the XConnect base station computer node, XC Desktop will display all parameters from the XC Setup on the XConnect base station computer.

  3. XC Desktop will automatically launch XC Setup. By default XC Setup will read and load in memory the XConnect.ini file.

  4. Review the station, sensor, com port and poll group parameters. All prior configuration information has been re-used by XConnect.

  5. Click on the System Init node ( [image]) in the tree view. The user must select the desired data storage option. After selecting the storage option, click the right-mouse button and select Save Changes.

  6. XC Desktop will instruct you to got the Data Storage Systems node ( [image]) to configure data storage settings.


Sutron Standard Protocol (SSP)

SSP is the communication protocol XConnect (and PcBase2) uses to communication with Sutron data loggers (8200/8210/9000/9210/XPert). SSP supports a set of commands to request and exchange data. The SSP Decoder translates the protocol message so the user can understand it. An SSP message follows a certain format and can have many possible operations codes (opcodes).

The Sutron Standard Protocol is a byte-oriented protocol using asynchronous, serial binary, half duplex transmissions with one start bit, one stop bit, no parity, and eight data bits. The protocol was developed as a layered structure following the International Standards Organization (ISO) model for Open Systems Interconnection (OSI).

The transmission rate is dependent on the communication devices. The protocol has been successfully implemented on 3 different physical links: radios, direct connect (RS-232) and telephone modems.

Anatomy of an SSP message

The standard message format includes header and data sections. The header begins with a DLE SOH (Data Link Escape, Start Of Header) and is terminated with a DLE STX (Data Link Escape, Start of Text); no control characters are allowed between them. The header contains a variable-length destination /source field for network control. The transparent binary data section begins after the STX, and the end of the transparent data is marked by a DLE ETX (Data Link Escape, End Of Text). The data section following the STX will contain a single flag byte, three bytes for a message sequence control, and a variable number of subfields. Each subfield will have a 1-byte opcode, a 2-byte count of data bytes and binary data. The packet ends with the DLE ETX followed by two block check characters. The block check is a CRC-16 performed on all bytes except the DLE SOH and includes the DLE ETX. In addition, the opcodes for each data subfield will instruct the device how to respond.

Every message begins with a DLE SOH followed by the DESTINATION/SOURCE field which are variable length fields delimited by a slash (/) and the DLE STX. All the bytes in the field must be printable. The destination is the address of the endpoint of the packet. The source is the address of the initiating device.

The STX delimits the end of the header and the beginning of the data. Data following the STX can be binary. This is called transparent text. The FLAG byte is reserved for future use.

|DLE|SOH|Destination|/|Source|DLE|STX|Flag|Seq|OpCode|Count|Data|OpCode|Count|Data|OpCode|.....|DLE|ETX|CRC|

Characters | Bytes | Description
DLE | 1 | DLE (Data Link Escape) marks the start of every SSP message
SOH | 1 | SOH (Start of Header) marks second character of every SSP message
Destination | variable | Recipient address (unit ID) of SSP message
/ | 1 | Delimiter between destination and source addresses.
Source | variable | Source address (unit ID) of SSP message
DLE | 1 | DLE (Data Link Escape)
STX | 1 | STX (Start of Text) marks start of data section
Flag | 1 | Reserved for future use.
Seq | 3 | Time Stamp
OpCode | 1 | SSP operation code
Count | 2 | Data count following
Data | variable | Data
..... | variable | Additional data (Opcode, Count and Data)
DLE | 1 | DLE (Data Link Escape)
ETX | 1 | ETX (End of Tex) marks end of data section
CRC | 2 | CRC-16 bytes

Example SSP messages

Current Data request

LC11,XCONNECT,64043039,OK,CurdataReq

To From Flag OpCode

Current Data response

A current data response returns all the data in one SSP packet and the SSP transaction is completed.

XCONNECT,LC11,645,OK,Curdata,Analog1,2,1,0.16980,2,OK,Analog2,2,1,0.14516,2,OK,Battery,2,1,0.00000,2,OK

To FromSeq OpCode Data

Date (TimeTag) Data request

LC11,XCONNECT,67754605,OK,TimeTagReq,Start 02/07/2003 00:00:00,Stop 02/07/2003 01:00:00

To From Seq OpCode OpCode parameters

Date (TimeTag) Data request

A timetag data response returns the data in one or multiple SSP packets depending how much data was requested. The recipient will send as much data as one SSP packet can hold, transfer the message, wait for an acknowledgement receipt from the sender. The recipient will then send the next packet and again wait for the acknowledge until all the data has be sent. The recipient will lastly send a time tag end message to indicate the SSP transaction is completed.

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:00:00,Real,0.18900,Real,0.17800,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:05:00,Real,0.18600,Real,0.17600,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:10:00,Real,0.18600,Real,0.16200,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:15:00,Real,0.18900,Real,0.16400,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:20:00,Real,0.18400,Real,0.15900,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:25:00,Real,0.18700,Real,0.15700,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:30:00,Real,0.18700,Real,0.15700,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,646,OK,TimeTag,02/07/2003 00:35:00,Real,0.18900,Real,0.16000,Real,0.00000

To FromSeq OpCode Data

LC11,XCONNECT,67758781,OK,Ack,TimeTag

To FromSeq OpCode Data Acknowledge end of First packet

XCONNECT,LC11,647,OK,TimeTag,02/07/2003 00:40:00,Real,0.19400,Real,0.17000,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,647,OK,TimeTag,02/07/2003 00:45:00,Real,0.18700,Real,0.18000,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,647,OK,TimeTag,02/07/2003 00:50:00,Real,0.18900,Real,0.17000,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,647,OK,TimeTag,02/07/2003 00:55:00,Real,0.18300,Real,0.17100,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,647,OK,TimeTag,02/07/2003 01:00:00,Real,0.18300,Real,0.15900,Real,0.00000

To FromSeq OpCode Data

XCONNECT,LC11,647,OK,TimeTagEnd

To FromSeq OpCode Indicate end of data

LC11,XCONNECT,67761606,OK,Ack,TimeTagEnd

To FromSeq OpCode Data Acknowlegge end of data/End of SSP message

Understanding the SSP Decoder Operation Codes

SSP Operation Code | Operation Code Number | Description
Ack | 00 | Acknowledge another opcode
Nak | 01 | Cannot acknowledge/perform opcode
CurdataReq | 02 | Request for current data
Curdata | 03 | Current data
TimeTagReq | 04 | Request for Timetag (log) data
TimeTag | 05 | Timetag data
TimeTagEnd | 06 | End of Timetag data
SelfTest | 07 | Perform a SelfTest
ClearStatus | 08 | Clear System Status
GetStatus | 09 | Request System Status
SystemStatus | 10 | Current System Status
StartSDL | 11 | Start SDL code running (9000 only)
StopSDL | 12 | Stop SDL code running (9000 only)
StartTag | 13 | Run Start SDL code for tag (9000 only)
EvalTag | 14 | Run Eval SDL code for tag (9000 only)
StopTag | 15 | Run Stop SDL code for tag (9000 only)
EOT | 16 | Must be same as DLE (Hex 16)
SetClock | 17 | Set Time of data logger to this time
Reset | 18 | Perform a Reset in the data logger
EraseSetup | 19 | Erases all setup information
SetupReq | 20 | Request for data logger setup
SetupInvalid | 21 | Setup is bad
SetupChanged | 22 | Setup is changed by terminal
TagInfo | 23 | Single tag setup descriptor info
TagData | 24 | Setup data for this tag
TagEnd | 25 | End of tag data
SetupEnd | 26 | End of setup information
ValueReq | 27 | Request for tag/sensor values
Value | 28 | Tag/sensor data
Alarm | 29 | Alarm/exception message
SelectControl | 30 | Select a control point/ tag (9000 only)
BeginControl | 31 | Begin a control point/tag (9000 only)
SWTableReady | 32 | RTU SW Flow table ready (customer specific)
Illegal | 33 | Illegal opcode received
Restricted | 34 | Opcode not available to user
Login | 35 | Request to login to data logger
BadPassword | 36 | Login attempt failed
PleaseLogin | 37 | User logged out
Logout | 38 | Log out of data logger
AllValueReq | 39 | Request all values for a tag/sensor
AllValue | 40 | All values for a tag
Mail | 41 | Mail message
Stopped | 42 | SDL Stopped
DDEPoke | 43 | DDE Poke message
DDE Request | 44 | DDE Request message
DDE Execute | 45 | DDE Execute message
DDE Initiate | 46 | DDE Initiate message
DDE Terminate | 47 | DDE Terminate message
DDE Advise | 48 | DDE Advise message
DDE Unadvise | 49 | DDE Unadvise message
BertStatusReq | 50 | Request BERT status
BertStatus | 51 | BERT status
BertClear | 52 | Clear BERT status
BertReq | 53 | Request a BERT message
Bert | 54 | Dummy BERT message
Alert | 55 | Alert message over SSP
RDIReq | 56 | Request for RDI tag data values
RDI | 57 | RDI tag values


Sensor Decoding

Decoding data means decoding the value correctly and the time stamp of the data value. The key to successful decoding is understanding the parameters that XC Decode uses. These parameters are like a road map into the satellite message string of characters.

The first 37 characters from each satellite messages conform to a NESDIS header format defined by NESDIS (National Environment Satellite, Data and Information Service connected with NOAA).

Decoding sensor value

If the satellite messages is binary (as in the below examples), written documentation on the transmission format from the DCP/RTU manufacturer is vital.

Once the header is read, XC Decode positions itself at the beginning of the data portion of the messages. At this point, the position is 1.

CE12265402365235959G46-3NN052WFF000292DEAap@JAAap@JAAap@JAgri¨

                                     1

Parameters involved in sensor decoding are:

Bound 1 and Bound 2 are used in conjunction with Block ID.

The Block ID is an optional parameter that will advance the position closer to the sensor value position. Thus, in looking for the Block ID, XC Decode will stay within Bound 1 and Bound 2 positions. If Bound 1 and Bound 2 are both left as 0, then XC Decode will search the whole message data portion for the Block ID.

The Block ID also serves as an additional message format check. XC Decode will first verify that the satellite ID is part of the XConnect station list. Next, XC Decode will look for the Block ID. If the Block ID is not found for that sensor, decoding will abort and XC Decode will move to next sensor. Thus, if another rogue DCP/RTU is using your satellite ID by mistake, XC Decode will not decode the incorrect data because the Block ID was not found.

Example 1

NESDIS HDR...000042B1DEAap@JAAap@JAAap@JAgri@OG@@J@@@///¨

12 4

1 **New position after finding Block ID

This represents a Sutron self-timed binary message. As defined by Sutron, the first sensor value is at position 4. If the user chose to look for a Block ID, then XC Decode would be instructed to look for B1 between positions 1 and 2.

After finding the Block ID, position is reset to 1.

Example 2

NESDIS HDR...00059:PC 5 #15 9.62 9.62 :HG 5 #15 7.97 7.96 :Bat 0 12.1 ¨

1

1 **New position after Block ID

This represents a Sutron selftimed ASCII SHEF message. Each sensor is preceded by sensor label that will represent the Block ID. If we are trying to decode HG (stage) sensor, the Block ID would be :HG and Bound 1 and Bound 2 would both be 0. By these settings, XC Decode is instructed to look in the entire message for the label :HG.

After finding the Block ID, position is reset to 1.

Pos indicates start position number after the NESDIS header or Block ID to start reading characters. For Sutron VAX customers, Pos is the same as the OFV value (Offset for First Value).

Example 1

NESDIS HDR...000045B1DEAap@JAAap@JAAap@JAgri@OG@@J@@@//G@@/¨

12 5

After adjusting to start position relative to the Block ID and according to the Sutron self-timed binary format, the first sensor value starts at the letter E which is position 2. Thus the first sensor would have a Pos value of 2. If a Block ID was not used, the Pos value would be 4 since it is the 4th character after the NESDIS header.

Example 2

NESDIS HDR...00059:PC 5 #15 9.62 9.62 :HG 5 #15 7.97 7.96 :Bat 0 12.1 ¨

1 8

After adjusting to start position relative to the Block ID, according to the Sutron self-timed ASCII shef format, the first sensor value is 7.97 position 8. Thus the first sensor would have a Pos value of 8. If a Block ID was not used, the Pos value would be 31 since it is the 31st character after the NESDIS header.

Size indicates how many bytes to read that equals one sensor value once at the Pos position.

The value of size is dependent on manufacturer transmission format.

Example 1

NESDIS HDR...000045B1DEAap@JAAap@JAAap@JAgri@OG@@J@@@//G@@/¨

2345

According to the Sutron self-timed binary format, the size of all binary encoded sensor value is 3.

Example 2

NESDIS HDR...00059:PC 5 #15 9.62 9.62 :HG 5 #15 7.97 7.96 :Bat 0 12.1 ¨

1 8

In the case of ASCII, the Size can have two possibilities. Some DCP/RTU manufacturer will format the sensor values in a message all with the same width (i.e., 5 characters) and pad with 0's. For example, the sensor values can appear as 07.97, 07.96, 07.97. For this example the size will be 5 (account for the decimal space).

If the width of the sensor value will vary, enter 0 for the Size. The special value of 0 will instruct XC Decode to continue to read until either a space, carriage turn or line feed is encountered. Using 0 as the Size, proves less prone to counting errors.

Next indicates how many characters to skip from Pos to reach the next occurrence of the sensor value if the number of sensor values to decode (Amount) is > 1. For Sutron VAX customers, Next is the same as the ONV (Offest to Next Value) value.

Example 1

NESDIS HDR...000045B1DEAap@JAAap@JAAap@JAgri@OG@@J@@@//G@@/¨

23456789AB

Using this example and according to the Sutron self-timed interleaved binary format, the Next value is equal to the total number of sensors multiplied by 3. As shown above, each sensor is color-coded. There are three sensors (shown in blue, fushia and green). The distance between the sensors shown in blue is 9 (3 sensors x Size of 3).

Example 2

NESDIS HDR...00059:PC 5 #15 9.62 9.62 :HG 5 #15 7.97 7.96 :Bat 0 12.1 ¨

89ABCD

In the case of ASCII, if a non-zero Size was used, such as 5 in the previous section, then the Next distance would be 6. Again, Next is the number of characters to skip to reach the next occurrence of the same sensor.

If 0 is used for the Size, then using the 0 for Next will indicated to XC Decode that the second occurrence of the sensor is immediately after the first.

Amount - How many values of each sensor does XC Decode need to decode. For Sutron VAX customers, Amount is the same as the NV value (Number of Values).

The number values for each sensor is determined by the DCP/RTU setup. If the sensor is measured every 15 minutes and the satellite transmission interval (provided by NESDIS) is 4 hours, then the amount of sensors is 16. There are 4-15 minute measurements per hour over 4 hours, thus 16.

Example 1

NESDIS HDR...000045B1DEAap@JAAap@JAAap@JAgri@OG@@J@@@//G@@/¨

23456789AB

Using this example and with the assistance of the color-coded sensors, there are 4 interleaved sets of sensors. Thus, the Amount for this example is 4.

Example 2

NESDIS HDR...00059:PC 5 #15 9.62 9.62 :HG 5 #15 7.97 7.96 :Bat 0 12.1 ¨

89ABCD

In the case of ASCII, it is very easy to count the number of sensor values. Thus, the Amount for this example is 3.

SkipLF, SkipComma, and SkipBlank all help advance the position closer to the starting position (Pos) of the sensor.

These parameters are useful if the satellite message contains line feeds (LF), comma, or blanks. These, like, the Block ID help provide an accurate road map closer to the starting position of the sensor. SkipBlank can be used in decoding the Sutron self-time ASCII SHEF message. Let's revisit Example 2 using SkipBlank.

Example 2

NESDIS HDR...00059:PC 5 #15 9.62 9.62 :HG 5 #15 7.97 7.96 :Bat 0 12.1 ¨

B B B1

Using the Block ID and SkipBlank parameters, we can quickly advance to the beginning of the sensor value. We will still use the :HG as the Block ID. Additionally, we can see that there 3 blanks between finding the Block ID and the beginning of the sensor value. Thus, without having to count any characters, we easily advance to the sensor value by using SkipBlank = 3. Finally, the Pos is then 1. The Size and Next parameters will remain 0 as above.

Example 3

45505E7202071110330G50-5NN019EFF00096

02.075 02.075 02.074

12.38 12.41 12.38

283 283 283

-25.1 -25.7 -26.3

064 064 064

The message in Example 3 is not a Sutron message. As you can see from the message, the data is separated into multiple lines. The easiest way to retrieve all the data is to use the SkipLF parameter. The sensor data on the second line is battery (12.38 12.41 12.38). Thus, using the parameters to quickly advance to the beginning of the line would be: SkipLF = 2, Pos = 1, Size = 0, Next = 0, and Amount = 3.

Each time a new line is started, there is an embedded character representing a Line Feed. It is an unprintable character, thus unseen, but still accounted for.

The parameters for the last line of data (064 064 064) would be:

SkipLF = 5, Pos = 1, Size = 0, Next = 0, and Amount = 3.

As you can see in this case, there is not unique block identifier or label to distinguish one set of numbers or the messages, thus Block ID is left blank (not used), Bound 1 and Bound 2 are 0.

Alternate decoding parameters option 2:

If SkipLF was not used, you could have counted the characters to the beginning of the each line. Do not forget that there is a blank space, a CR (carriage return) and LF (line feed) at the end of each line that need to be counted! In that case the battery decoding parameters would be:

Pos = 27, Size = 0, Next = 0, and Amount = 3.

Alternate decoding parameters option 3:

Further, if you chose not use the Size equal to 0, the decoding parameters would be:

Pos = 27, Pos = 1, Size = 5, Next = 6, and Amount = 3.

All three sets of decoding parameters will decode the same value. The second and third set require more counting and is more prone to errors.

Decoding sensor time stamp

Written documentation on the transmission format from the DCP/RTU manufacturer is also vital for understanding the time order of the sensor values. As seen in the examples above, many satellite messages do not contain time information with the sensors. It is key to remember that each transmission must be complete within XX seconds.

Interval represents the measurement time difference between the decoded sensor values.

As indicated in the Sutron transmission format, the newest measured data is ordered first and the oldest measured data last. So, for Sutron, the value will always be the negative of the measurement interval in the DCP/RTU, typically -00:15:00.

For some DCP/RTU manufacturers, the sensor ordering is oldest to newest, so the Interval will be a positive value, 00:15:00.

Offset represents the time difference between the message transmission time and the measurement time of first sensor value in message.

In many cases, the only reference to any time in the satellite messages is in the NESDIS header. This time can help XC Decode derive the measurement time of the sensor values. If the transmission time of a DCP is 18:47:50, and the measurement cycle of the sensor is 00:15:00, then the Offset time will be 00:02:50. If the sensor is measured every 15 minutes, then the last time of measurement before transmission was 18:45:00. The difference between 18:47:50 minus 18:45:00 is 00:02:50.

RoundOff helps round the calculated time to whole minutes or hours before storing to data storage option.

The rounding of the time stamp is more important with the PcBase2 binary file data storage option. The binary data files are essentially, fixed interval files. The fixed interval file is determined by the XC Desktop Data Storage setup parameters. In creating a binary data file, the user must specify the Start date/Time and Interval of the file. Thus, if the Interval of the binary file is 00:15:00, then the only available storage times in the file will be 00:00:00, 00:15:00, 00:30, 00:45:00, 01:00:00, 01:15:00...etc. So, the time and date calculated for the sensor values will have to be stored in one of the pre-determined time slots. Rounding the calculated time ensures no confusion on the part of XC Decode with regard to accurate data storage. Without rounding, XC Decode will determine the closes time slot to store the sensor data.

The rounding of time for the database data storage option provides a nice consistent, incremental time stamp for all the sensor values.

Example

CE12265402305205014G46-3NN052WFF00059:PC 5 #15 9.62 9.62 :HG 5 #15 7.97 7.96...¨

        YYDDDHHMMSS                         O  I

The above message, according to the header, the message was transmitted year 2002, julian day 305 (November 1) at 20:50:14 (8:50:14 pm). According to the Sutron self-timed ASCII SHEF format, the position marked with the yellow 'O' represents the offset value.

Actual sensor measurement time = Transmission time - Offset (minutes).

20:45:14 = 20:50:14 - 00:05:00

The yellow 'I' represents the data interval. The Interval indicates that the sensor values were measured 15 minutes apart. For Sutron data, the 15 is negative. So, the :

First sensor value (:PC or :HG) was measured at 20:45:14.

Second sensor value (:PC or :HG) was measured at 20:30:14.

Third sensor value (:PC or :HG) was measured at 20:15:14.

Using an optional RoundOff value of 00:15:00 which matches the measurement interval will adjust the time to: 20:45:00. 20:30:00, 20:15:00 prior to data storage.


Sutron transmission format

Sutron Satellite Transmission format

The Sutron dataloggers support 4 different transmission formats, they are:

  1. Random Binary (6-bit binary code)

  2. Self Timed Binary Interleaved (6-bit binary code)

  3. Self Timed ASCII SHEF (Standard Decimal Format, similar to SHEF)

  4. Self Timed Binary Non-Interleaved (6-bit binary code - XPERT/XLITES only)

Below is first describes the general transmission format followed by details on each of the formats transmitted by the Sutron dataloggers.

RANDOM BINARY DATA FORMAT

This format is used when the Sutron RTU makes a random or alarm transmission. The format of the transmission data is:

<GROUP-ID> <OFFSET>

<SENSOR1-DATA> <SENSOR2-DATA> ... <SENSOR(N)-DATA>

<SENSOR1-DATA> <SENSOR2-DATA> ... <SENSOR(N)-DATA>

<SENSOR1-DATA> <SENSOR2-DATA> ... <SENSOR(N)-DATA>

...

<EXTERNAL DATA><COUNTER><BATTERY><LAT/LONG>

where:

GROUP-ID

The GROUP-ID is a one byte character, in the range 2 to 9, indicating the random group which caused the transmission.

OFFSET

OFFSET is a 1 byte binary encoded number indicating the number of minutes ago the most recent data was recorded.

SENSOR-DATA

The actual SENSOR-DATA contains only those sensors belonging to the random group which caused the alarm. The data values are 3 byte binary encoded signed numbers allowing a range of: -131072 to +131071. The actual 6-bit binary encoded format is described later. The Sutron RTU will only transmit numbers in the range -32768 to +32767. The value transmitted is taken directly from the log of the Sutron RTU which was scaled by Rightdigits before being placed in the log. The value transmitted will be value * 10^RightDigits. The string "///" will be sent if the data was never recorded or was erased.

For 8200/8210 data loggers, the number of sensors values transmitted depends on the number of sensors in the random group, and the number of log records sent depends on #Data/TX RR selected in the Sutron RTU. The most recent data is always sent first. Note: if #Measmnt/Log is set > 1, the first value transmitted is the last measured value, not the last logged value. This has been done to support users who want data logged hourly (to conserve space) and still transmit randomly a value collected more often. Since the number of values transmitted for each sensor is the same, the values are interleaved (a set of sensors values are transmitted at a time).

For XPert/XLite/SatLink data loggers, the number of sensor values is set separately for each measurement in the Random Transmisssions, Num values to Tx field. As a result, the Satlink will send all the required values for one sensor (most recent first) before proceeding to the next sensors. These values are non-interleaved.

EXTERNAL DATA

For SatLink data loggers only, this is data given to the SatLink by a device through the RS-232 port. This is untouched by the SatLink Logger. It gets transmitted in the same way it was received.

LAT/LONG

For data loggers using SatLink transmitters only, this is an optional field. It will only be included if the Append Lat/Long parameter is selected for random transmissions. XConnect cannot decode LAT/LONG.

LAT/LONG can manually be decoded into D:M:S format by converting the binary values to decimal and applying the following formula:

  • Degrees latitude = 64 * ( 1st-byte AND 63 ) + ( 2nd-Byte AND 63) - 180.

  • Minutes latitude = 3rd-byte AND 63Seconds latitude = 4th-byte AND 63.

  • Degrees longitude = 64 * ( 5th -byte AND 63) + ( 6th -Byte AND 63) - 180.

  • Minutes longitude = 7th-byte AND 63Seconds longitude = 8th-byte AND 63.

  • For example BAAODAXe would be decoded as Lat N 39o 1' 15.79" Long W 77o 24' 37.19".

COUNTER

COUNTER is a 2 byte binary encoded number which indicates the transmission number and increments after every transmission. The number will be between 0 and 4095.

BATTERY

BATTERY is a 1 byte binary encoded number representing the battery voltage of the Sutron RTU before the transmission. The range of the number will be -32 to +31 and can be converted to volts by multiplying by 0.234 and adding 10.6 allowing a range of 3.1 to 18.1 volts.

EXAMPLE 1:

Here is a message with 2 data items per transmission and with three sensors enabled in random group 2.

This message assumes that #measmnt/log = 1.

2@@Gt@Sx@@i@Gs@Sr@@i@GI

||| | | | | | | |

||| | | | | | | +- Battery Voltage

||| | | | | | +--- Random Counter

||| | | | | +------ Temp #2

||| | | | +--------- Precip #2

||| | | +------------ Stage #2

||| | +--------------- Temp #1

||| +------------------ Precip #1

||+--------------------- Stage #1

|+---------------------- Delta Time

+----------------------- Group ID

The time stamp for the values is based on DatTimRR and DatIntRR. A transmission made at 10:28 would have the 10:15 (#1) and 10:00 (#2) data if DatTimRR=00:00:00 and DatIntRR=00:15:00. If DatTimRR=00:00:00 and DatIntRR=01:00:00 the data would be at 10:00 (#1) and 9:00 (#2)

EXAMPLE 2:

If #measmnt/log were > 1, the message would appear as follows:

Here is a message with 2 data items per transmission and with

three sensors enabled in random group 2:

2@@Gt@Sx@@i@Gs@Sr@@i@GI

||| | | | | | | |

||| | | | | | | +- Battery Voltage

||| | | | | | +--- Random Counter

||| | | | | +------ Temp #1 (based on DatTimRR and DatIntRR)

||| | | | +--------- Precip #1 (based on DatTimRR and DatIntRR)

||| | | +------------ Stage #1 (based on DatTimRR and DatIntRR)

||| | +--------------- Temp #1 (last measured value)

||| +------------------ Precip #1 (last measured value)

||+--------------------- Stage #1 (last measured value)

|+---------------------- Offset Time

+----------------------- Group ID

EXAMPLE 3:

2@@Gt@Gs@Sx@Sr@@i@@iEXTBAAODAXe@GI

||| | | | | | | | | |

||| | | | | | | | | +- Battery Voltage

||| | | | | | | | +--- Random Counter

||| | | | | | | +----------- Latitude/Longitude (optional)

||| | | | | | +-------------- External Data (EXT given by external RS-232 device)

||| | | | | +----------------- Temp #2

||| | | | +-------------------- Temp #1

||| | | +----------------------- Precip #2

||| | +-------------------------- Precip #1

||| +----------------------------- Stage #2

||+-------------------------------- Stage #1

|+--------------------------------- Delta Time

+---------------------------------- Group ID = 2

The time stamp for these values is a bit different than that in the first example. In this later case, the Sutron RTU sends the last measured value for each sensor first. The time stamp for these sensors would be the last nearest measurement time. The first data from the log (#1) would have the same time stamp as before.

SELF TIMED BINARY INTERLEAVED DATA FORMAT

This format is used when the Sutron RTU makes a self-timed transmission and the format has been set to BINARY. The format of the transmission data is:

<BLOCK-IDENTIFIER> <GROUP-ID> <OFFSET>

<SENSOR1-DATA> <SENSOR2-DATA> ... <SENSOR(N)-DATA>

<SENSOR1-DATA> <SENSOR2-DATA> ... <SENSOR(N)-DATA> ...

<SENSOR1-DATA> <SENSOR2-DATA> ... <SENSOR(N)-DATA>

<EXTERNAL DATA><COUNTER><BATTERY><LAT/LONG>

where:

BLOCK-IDENTIFIER

BLOCK-IDENTIFIER is always sent as "B" to indicate the start of a binary data group.

GROUP-ID

GROUP-ID is always sent as "1" to indicate the self timed group.

OFFSET

After the group id, the actual data from the Sutron RTU's log are sent. Each record is prefixed with an <OFFSET>, which is a 1 byte binary encoded number indicating the number of minutes ago the most recent data was recorded.

SENSOR-DATA

SENSOR-DATA contains only those sensors belonging to the self timed group (number 1). The data values are 3 byte binary encoded signed numbers allowing a range of: -131072 to +131071. The actual 6-bit binary encoded format is described later. The Sutron RTU will only transmit numbers in the range -32768 to +32767. The value transmitted is taken directly from the log of the Sutron RTU which was scaled by RightDigits before being placed in the log. The value transmitted will be value * 10^RightDigits. The string "///" will be sent if the data was never recorded or was erased.

For 8200/8210 data loggers, the number of sensors values transmitted depends on the number of sensors in the random group, and the number of log records sent depends on #Data/TX ST selected in the Sutron RTU. The most recent data is always sent first. Note: if #Measmnt/Log is set > 1, the first value transmitted is the last measured value, not the last logged value. This has been done to support users who want data logged hourly (to conserve space) and still transmit randomly a value collected more often. Since the number of values transmitted for each sensor is the same, the values are interleaved (a set of sensors values are transmitted at a time).

EXTERNAL DATA

For SatLink data loggers only, this is data given to the SatLink by a device through the RS-232 port. This is untouched by the SatLink Logger. It gets transmitted in the same way it was received.

BATTERY

BATTERY is a 1 byte binary encoded number representing the battery voltage of the Sutron RTU before the transmission. The range of the number will be -32 to +31 and can be converted to volts by multiplying by 0.234 and adding 10.6 allowing a range of 3.1 to 18.1 volts.

LAT/LONG

For data loggers using SatLink transmitters only, this is an optional field. It will only be included if the Append Lat/Long parameter is selected for random transmissions. XConnect cannot decode LAT/LONG.

LAT/LONG can manually be decoded into D:M:S format by converting the binary values to decimal and applying the following formula:

  • Degrees latitude = 64 * ( 1st-byte AND 63 ) + ( 2nd-Byte AND 63) - 180.

  • Minutes latitude = 3rd-byte AND 63Seconds latitude = 4th-byte AND 63.

  • Degrees longitude = 64 * ( 5th -byte AND 63) + ( 6th -Byte AND 63) - 180.

  • Minutes longitude = 7th-byte AND 63Seconds longitude = 8th-byte AND 63.

  • For example BAAODAXe would be decoded as Lat N 39o 1' 15.79" Long W 77o 24' 37.19".

EXAMPLE 1:

Here is a message with 2 data items per transmission and with three sensors enabled in the self-timed group:

B1@@Gt@Sx@@i@Gs@Sr@@iI

|||| | | | | | +--- Battery Voltage

|||| | | | | +------ Temp #2

|||| | | | +--------- Precip #2

|||| | | +------------ Stage #2

|||| | +--------------- Temp #1

|||| +------------------ Precip #1

|||+--------------------- Stage #1

||+---------------------- Delta Time

|+----------------------- Group ID

+------------------------ Block ID

SELF TIMED BINARY NON-INTERLEAVED DATA FORMAT

This format is used when the XPERT/XLITE makes a self-timed transmission and the format has been set to BINARY/NON-INTERLEAVED. The format of the transmission data is:

<BLOCK-IDENTIFIER> <GROUP-ID> <OFFSET>

<SENSOR1-DATA> <SENSOR1-DATA> ... <SENSOR1-DATA>

<SENSOR2-DATA> <SENSOR2-DATA> ... <SENSOR2-DATA> ... <SENSOR2-DATA>

<SENSOR(N)-DATA> <SENSOR(N)-DATA>

<BATTERY>

where:

BLOCK-IDENTIFIER

BLOCK-IDENTIFIER is always sent as "B" to indicate the start of a binary data group.

GROUP-ID

GROUP-ID is always sent as "1" to indicate the self timed group.

OFFSET

After the group id, the actual data from the Sutron RTU's log are sent. Each record is prefixed with an <OFFSET>, which is a 1 byte binary encoded number indicating the number of minutes ago the most recent data was recorded.

SENSOR-DATA

SENSOR-DATA contains only those sensors belonging to the self timed group (number 1). The data values are 3 byte binary encoded signed numbers allowing a range of: -131072 to +131071. The actual 6-bit binary encoded format is described later. The Sutron RTU will only transmit numbers in the range -32768 to +32767. The value transmitted is taken directly from the log of the Sutron RTU which was scaled by RightDigits before being placed in the log. The value transmitted will be value * 10^RightDigits. The string "///" will be sent if the data was never recorded or was erased.

For XPert/XLite/SatLink data loggers, the number of sensor values is set separately for each measurement in the Scheduled Transmisssions, Num values to Tx field. As a result, the Satlink will send all the required values for one sensor (most recent first) before proceeding to the next sensors. These values are non-interleaved.

BATTERY

BATTERY is a 1 byte binary encoded number representing the battery voltage of the Sutron RTU before the transmission. The range of the number will be -32 to +31 and can be converted to volts by multiplying by 0.234 and adding 10.6 allowing a range of 3.1 to 18.1 volts.

LAT/LONG

For data loggers using SatLink transmitters only, this is an optional field. It will only be included if the Append Lat/Long parameter is selected for random transmissions. XConnect cannot decode LAT/LONG.

LAT/LONG can manually be decoded into D:M:S format by converting the binary values to decimal and applying the following formula:

  • Degrees latitude = 64 * ( 1st-byte AND 63 ) + ( 2nd-Byte AND 63) - 180.

  • Minutes latitude = 3rd-byte AND 63Seconds latitude = 4th-byte AND 63.

  • Degrees longitude = 64 * ( 5th -byte AND 63) + ( 6th -Byte AND 63) - 180.

  • Minutes longitude = 7th-byte AND 63Seconds longitude = 8th-byte AND 63.

  • For example BAAODAXe would be decoded as Lat N 39o 1' 15.79" Long W 77o 24' 37.19".

EXAMPLE 1:

Here is a message with three sensors enabled each with a different number of data items in the selftimed group:

B1@@Gt@Gs@Sx@Sr@@i@@iEXTIBAAODAXe

|||| | | | | | | ||

|||| | | | | | | |+-------- Latitude/Longitude (optional)

|||| | | | | | | +--------- Battery Voltage (optional)

|||| | | | | | +------------ External

|||| | | | | +--------------- Temp #2

|||| | | | +------------------ Temp #1

|||| | | +--------------------- Precip #2

|||| | +------------------------ Precip #1

|||| +--------------------------- Stage #2

|||+------------------------------ Stage #1

||+------------------------------- Delta Time

|+-------------------------------- Group ID

+--------------------------------- Block ID

SELF TIMED ASCII SHEF DATA FORMAT

This format is used when the Sutron RTU makes a self-timed transmission and the format has been set to SHEF. The format of the transmission data is:

":" <NAME1> <OFFSET> "#"<INTERVAL> <DATA1> <DATA1> ... <DATA1>

":" <NAME2> <OFFSET> "#"<INTERVAL> <DATA2> <DATA2> ... <DATA2> ...

":" <NAME(N)> <OFFSET> "#"<INTERVAL> <DATA(N)> <DATA(N)> ... <DATA(N)>

":" <EXTERNAL DATA>

":" <BATTERY-NAME> <OFFSET> <BATTERY>

<LAT/LONG>

where:

NAME

NAME is the sensor name or SHEF CODE as entered in the Sutron RTU in the enable sensor menu. SHEF CODES are usually two digit codes and you will have to look up the appropriate codes for your sensors. So, for instance the SHEF CODE for gage height is HG, cumulative precipitation is PC, air temperature is TA, and battery voltage is VB.

OFFSET

OFFSET After the group id, the actual data from the Sutron RTU's log are sent. Each record is prefixed with an <OFFSET>, which is an ASCII number indicating the number of minutes ago the most recent data was recorded.

INTERVAL

INTERVAL indicates the interval in minutes between transmitted sensor data items. The Sutron RTU always uses the same interval for every sensor. The interval is called the Data Interval in the Sutron RTU GOES setup menu.

SENSOR-DATA

Unlike the binary formats, the SHEF format groups all the related sensor <DATA> together. So, the data line for precipitation would contain the most recent precip data first followed by the next oldest, etc. One entry is generated for each sensor in the self timed group (number 1). The data is transmitted in ASCII with sign and decimal point (if needed). If a data value has not yet been recorded (or has been erased) the letter "M" for missing data will be sent.

The number of sensors transmitted depends on the number of sensors in the self timed group, and the number of log records sent depends on the Number of Data Items selected in the Sutron RTU. The most recent data is always sent first.

EXTERNAL DATA

For SatLink data loggers only, this is data given to the SatLink by a device through the RS-232 port. This is untouched by the SatLink Logger. It gets transmitted in the same way it was received.

BATTERY

After all of the sensors and data have been sent on last entry will be transmitted containing the battery voltage. <BATTERY-NAME> will contain the SHEF code assigned to Battery voltage in the Sutron RTU. <OFFSET> will be the same as for other entries and <BATTERY> will contain the Sutron RTU battery voltage as measured just before transmitting.

LAT/LONG

For data loggers using SatLink transmitters only, this is an optional field. It will only be included if the Append Lat/Long parameter is selected for random transmissions. XConnect cannot decode LAT/LONG.

LAT/LONG can manually be decoded into D:M:S format by converting the binary values to decimal and applying the following formula:

  • Degrees latitude = 64 * ( 1st-byte AND 63 ) + ( 2nd-Byte AND 63) - 180.

  • Minutes latitude = 3rd-byte AND 63Seconds latitude = 4th-byte AND 63.

  • Degrees longitude = 64 * ( 5th -byte AND 63) + ( 6th -Byte AND 63) - 180.

  • Minutes longitude = 7th-byte AND 63Seconds longitude = 8th-byte AND 63.

  • For example BAAODAXe would be decoded as Lat N 39o 1' 15.79" Long W 77o 24' 37.19".

EXAMPLE:

Here is a message with 2 data items per transmission and with three sensors enabled in the selftimed group, notice how much longer this message is compared to the earlier binary examples:

:HG 0 #15 10.20 10.15 :PC 0 #15 50 49 :TA 0 #15 -22.1 -22.0 :VB 0 12.2

| | | | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | | | | +- VB reading

| | | | | | | | | | | | | | | | + -- Offset time

| | | | | | | | | | | | | | | +------ Sensor Name, VB

| | | | | | | | | | | | | | +------------- TA #2

| | | | | | | | | | | | | +------------------- TA #1

| | | | | | | | | | | | +---------------------- Interval

| | | | | | | | | | | +------------------------- Offset time

| | | | | | | | | | +---------------------------- Sensor Name, TA

| | | | | | | | | +-------------------------------- PC #2

| | | | | | | | +----------------------------------- PC #1

| | | | | | | +-------------------------------------- Interval

| | | | | | +----------------------------------------- Offset time

| | | | | +-------------------------------------------- Sensor Name, PC

| | | | +--------------------------------------------------- HG #2

| | | +--------------------------------------------------------- HG #1

| | +------------------------------------------------------------ Interval

| +--------------------------------------------------------------- Offset time

+------------------------------------------------------------------ Sensor Name, HG

Note: the names HG, PC, TA are the sensor names assigned by the person setting up the Sutron RTU. If the default names are used they might be Encoder1 (HG), Counter (PC), Analog1 (TA), Battery (VB).

SIX-BIT BINARY ENCODED FORMAT

The six bit binary format is used to encode numbers into displayable ASCII characters. Notice that fractional numbers cannot be represented, so for instance a battery voltage of 13.04 volts setup with 2 right digits will be sent as 1304.

  • A 1 byte encoded number can range from -32 to +31.

  • A 2 byte encoded number can range from -2048 to +2047

  • A 3 byte encoded number can range from -131072 to +131071

Binary encoded numbers are always sent most significant bytes first. The number itself is broken down into 6-bit digits, and each digit is placed in one byte of data. The number 64 (ASCII "@") is added to each digit to make it fall within the range of displayable ASCII characters. The only exception is that 127 (ASCII <DEL>) is sent as 63 (ASCII "?")

Example 1. Encoding the number 10 in 1 byte:

  • Since 10 will fit in 6-bits we only have to add 64 which would yield 74. So the number 10 would appear as ASCII 74 or the letter "J".

Example 2. Encoding the number 12345 in 3 bytes:

  • First we have to convert 12345 into binary in 6-bit pieces:

12345 (base 10) = 11 000000 111001 (base 2)

  • Now we can convert each piece back to base 10:

11 000000 111001 (base 2) = 3, 0, 57

  • Finally, we add 64 to each piece and convert to ASCII:

67, 64, 121 = ASCII "C@y"

Example 3. Encoding the number -12345 in 3 bytes:

  • First we have to convert -12345 into two's complement 18-bit binary:

-12345 (base 10) = 111100 111111 000111 (base 2)

  • Now we can convert each piece back to base 10:

111100 111111 000111 (base 2) = 60, 63, 7

  • Finally, we add 64 to each piece and convert to ASCII (since the second piece is 63 we leave it alone):

124, 63, 71 = ASCII "|?G"

Example 4. Decoding the 3 byte string "@SW":

This is just like encoding except we follow the steps backwards.

  • First we convert all the characters to ASCII decimal codes:

ASCII "@SW" = 64, 83, 87

  • Now we subtract 64 from each piece and convert to 6 bit binary:

0, 19, 23 = 000000 010011 010111

  • Finally, we combine all the bits to form one 18-bit twos complement number and convert to base 10:

000000010011010111 = 1239


NESDIS header

NESDIS Header Field Description

CE12265402365235959G46-3NN052WFF00029@DEAap@JAAap@JAAap@JAgri¨

1       2 3  4 5 6 78 9 ABC  DE F    G                       H

Field #

Byte Length

Range

Description

1

8

0-9,A-F

Satellite ID, Platform ID, DCP Address

2

2

00-99

Year message was received relative to GMT

3

3

000-365

Julian day message was received relative to GMT

4

2

00-23

Hour message was received relative to GMT

5

2

00-59

Minute message was received relative to GMT

6

2

00-59

Second message was received relative to GMT

7

1

G,?,W,A,B,T,U, M,I,N,Q,C,S

Failure Code

G - Good Message

? - Message received with parity errors

M - Missing message

S - Short or Truncated message (Sutron Only)

THE FOLLOWING CODES ARE USED BY NESDIS ONLY:

W - Message received on wrong channel

D - Message received on multiple channel (duplicate)

A - Message received with address error(s) (correctable)

B - Message received with bad address (not correctable)

T - Message received late/early (time error)

U - Unexpected message

I - Invalid address

N - PDT entry for platform not complete

Q - Bad quality measurements

C - Comparison error on test transmission

Note: The PDT is NESIDS's platform description table.

8

2

32-57

Signal Strength of received message in dB.

Normal operation is 44-48.

Reliable data can be received as low as 37 if not other signal problem exists.

9

2

0,1,2...9,A

-1,-2...-9,-A

Frequency Offset in 50 Hz increments.

0=0-49 Hz, 1=40-99 Hz,...8=400-449 Hz, A=500-549 Hz.

A minus sign indicates the same range only below the center frequency.

A

1

N,H,L

Modulation Index or Phase Deviation

N = Normal, 60 +/- 5 degrees

H = High, > 70 degrees

L = Low, < 50 degrees

B

1

N,H,P

Modulation Quality

N = Normal, error rate better than 1x10-6

F = Fair, error rate between 1x10-4 and 1x10-6

P = Poor, error rate worse than 1x10-4

C

3

000-999

Channel message was received on

D

1

E,W,C,A

Satellite Spacecraft Location

E - GOES East

W = GOES West

C = GOES Central (not currently used)

THE FOLLOW CODES HAVE BEEN DEFINED BY SUTRON TO SUPPORT NON-GOES SATELLITES:

A = ARGOS (Never see this from NESDIS)

E

2

FF

Uplink carrier status (not used, always FF)

F

5

00000-15750

Message Data Length (plus 4 bytes to account for satellite ID which used to be contained in the message + 1 byte for the EOT stored as a blank space at the end).

In the example, there are acutally only 24 bytes of data, however, 24+4+1 or 29 is the actual number stored in the data length.

G

Message Data Length minus 5

!-~,CR,LF, SPACE

Message data.

Can be continued on multiple lines separated by a CR and a LF.

H

1

¨

Blank space representing EOT (End of Transmission) at end of message.


Rating/Lookup Tables

A rating/lookup table is an ASCII comma separated file with an extension of ".TBL" which should be stored in the directory specified by Table Path in either the XC Rtu setup window or the XC Decode setup window. The file can contain any number of comment lines which must begin with a semi-colon at the beginning of the line. The first non-comment in the file must contain the table type. Following is a list of valid table types:

  • LINEAR - Linear X axis, and Linear Y axis lookup table

  • SEMILOGX - Logarithmic X axis, and Linear Y axis lookup table

  • SEMILOGY - Linear X axis, and Logarithmic Y axis lookup table

  • LOGLOG - Logarithmic X axis, and Logarithmic Y axis lookup table

  • GSLINEAR - USGS Standard Rating table using Linear X and Y axis.

  • GSLOGLOG - USGS Standard Rating table using Logarithmic X and Y axis.

Following the table type is the data points of the table. All data points are assumed to be in user units (for instance X axis in FT, and Y axis in FLOW). LINEAR, SEMILOGX, SEMILOGY, and LOGLOG tables consists of rows of X,Y data points. GSLINEAR and GSLOGLOG consists of rows of X, Y, OFFSET, SHIFT data points. Each data point must be on a separate line. The amount of data contained in a table is only limited by the amount of free memory in the computer as the all accessed tables are stored in memory. Use an ASCII edit such as Notepad to create the rating table. Microsoft Word is NOT an ASCII editor, it is a word processing application that will embed formatting characters. If using Microsoft Word, save files on as Text Only.

Example 1

LINEAR

;VOLTS,Degrees F

0.0,0.0

1.0,20.0

2.0,40.0

3.0,60.0

4.0,80.0

5.0,100.0

Example 2

GSLOGLOG

;STAGE (FT), FLOW (CFS), OFFSET, SHIFT

0.00,0.000,1,0

1.07,0.000,1,0

1.12,0.050,1,0

1.15,0.090,1,0

1.18,0.140,1,0

1.22,0.210,1,0

1.27,0.320,1,0

1.37,0.670,1,0

1.45,1.080,1,0

1.59,2.160,1,0

1.66,2.850,1,0

1.72,3.600,1,0

1.78,4.450,1,0

1.90,6.300,1,0


XConnect Database Schema

XConnect consists of a set of 4 “management” tables and a set of 4 "data" tables. The XConnect tables are designed to provide a great deal of flexibility in:

  • Naming of stations and data parameters

  • Grouping data through such attributes as river basin or political boundaries

  • Managing the size of data tables so that performance is maximized

The four management tables are:

  1. XC_SITES - Contains stations in XConnect system.

  2. XC_SITESENSORS - Contains sensors of stations in XConnect system.

The four data tables are:

  1. XC_DATA1 - Contains numerical sensor data.

  2. XC_TXTDATA1 - Contains text sensor data.

  3. XC_PPDATA1 - Contains data from post-processing instructions and operations.

  4. XC_GOESQC - Contains satellite message quality data.

  5. XC_RTUQC - Contains SSP communication data.

XC_SITES

Name | Data Type | Length | Required | Description
STATION_ID (PK) | Character | 20 | Y | Name of station in XConnect
ENABLED | Character | 1 | Y | Active station (Y/N)
UNIT_ID | Character | 15 | N | RTU Unit ID
SITE_COMMENT | Character | 32 | N | General purpose string for comments on station
INSTALLATION_DATE | Date |  | N | Date station was installed
AGENCY | Character | 32 | N | Agency or organization that owns the station
COUNTRY | Character | 32 | N | Country where site is located
DISTRICT | Character | 32 | N | District where station is located
CITY | Character | 32 | N | City where station is located
STATE | Character | 32 | N | State where station is located
COUNTY | Character | 32 | N | County where station is located
BASIN | Character | 32 | N | Rriver basin where station is located
LATITUDE | Number |  | N | Latitude of station location
LONGITUDE | Number |  | N | Longitude of station location
ELEVATION | Number |  | N | Elevation of station
WEIGHTING_FACTOR | Number |  | N | Precipation station weighting for map calculation
COEFFICIENT1 | Number |  | N | General purpose coefficient 1
COEFFICIENT2 | Number |  | N | General purpose coefficient 2
COEFFICIENT3 | Number |  | N | General purpose coefficient 3
SATELLITE_ID | Character | 8 | N | Satellite/NESDIS identifier
PRIMARY_CHANNEL | Number |  | N | Primary satellite transmission channel
RANDOM_CHANNEL | Number |  | N | Secondary satellite transmission channel
REPORTING_TIME | Time |  | N | Assigned satellite transmission time slot
REPORTING_INTERVAL | Number |  | N | Assigned satellite transmission interval
LAST_UPDATE | Date |  | N | Time of last data received for station
TZONE_CODE | Character | 3 | N | ASCII time zone code, e.g., EST
GMT_OFFSET | Number |  | N | Time zone offset from GMT
SHEF_ID | Character | 8 | N | SHEF code for station
ALTERNATE_CHAR_ID_1 | Character | 10 | N | Alternate character ID 1
ALTERNATE_CHAR_ID_2 | Character | 10 | N | Alternate character ID 2
GPSTRING1 | Character | 20 | N | General purpose string 1
GPSTRING2 | Character | 20 | N | General purpose string 2
GPNUMBER1 | Number |  | N | General purpose number 1
GPNUMBER2 | Number |  | N | General purpose number 2
SETUP_FILE_NAME | Character | 255 | N | Filename of data logger setup file
PICTURE_FILE_NAME | Character | 255 | N | Filename of image of station

XC_SITESENSORS

Name | Data Type | Length | Required | Description
STE_STATION_ID (FK) | Character | 20 | Y | Name of station in XConnect
SENSORNAME (PK) | Character | 12 | Y | Name of sensor in XConnect
ENABLED | Character | 1 | Y | Active sensor enabled for porcessing (Y/N)
DATA_TABLE | Character | 10 | Y | Data table name where sensor is stored
DESCRIPTION | Character | 32 | N | General purpose string for comments on sensor
MANUFACTURER | Character | 20 | N | Manufacturer of sensor
MODEL_NUMBER | Character | 20 | N | Model number of sensor
SHEF_PE_CODE | Character | 7 | N | SHEF code for sensor
PARAMETER_CODE | Character | 12 | N | Parameter code applied for sensor
ALT_PARAMETER_CODE_1 | Character | 12 | N | Alternate parameter code 1
ALT_PARAMETER_CODE_2 | Character | 12 | N | Alternate parameter code 2
EQUATION | Character | 128 | N | Equation applied to sensor
RATING_TABLE | Character | 128 | N | Filename of rating/lookup table applied to sensor
OFFSET | Number |  | N | General purpose offset number
SHIFT | Number |  | N | General purpose shift number
HIGH_HIGH_LIMIT | Number |  | N | High high limit for sensor
HIGH_HIGH_ALARM | Number |  | N | How to apply High High limit: NONE, ABOVE, BELOW
HIGH_LIMIT | Number |  | N | High limit for sensor
HIGH_ALARM | Number |  | N | How to apply High limit: NONE, ABOVE, BELOW
LOW_LIMIT | Number |  | N | Low limit for sensor
LOW_ALARM | Number |  | N | How to apply Low limit: NONE, ABOVE, BELOW
LOW_LOW_LIMIT | Number |  | N | Low low limit for sensor
LOW_LOW_ALARM | Number |  | N | How to apply Low Low limit: NONE, ABOVE, BELOW
ROC_LIMIT | Number |  | N | Rate of change limit for sensor (per second)
ROC_ALARM | Number |  | N | How to apply Rate of Change limit: NONE, ABOVE, BELOW
ROC_INTERVAL | Number |  | N | Interval (seconds) over which rate of change is computed
DEADBAND | Number |  | N | Tolerance or allowable change in No Change where the alarm will not trigger
NO_CHANGE_INTERVAL | Number |  | N | Maximum time allowed for no change in sensor value expressed in days and fractions
NO_CHANGE_ALARM | Number |  | N | How to apply No Change limit: NONE, ON
TEXT_LIMIT | Character | 32 | N | Text that corresponds to an alarm condition for a text sensor data
TEXT_ALARM | Number |  | N | How to apply Text alarm: NONE, ON
COEFFICIENT1 | Number |  | N | General purpose coefficient 1
COEFFICIENT2 | Number |  | N | General purpose coefficient 2
COEFFICIENT3 | Number |  | N | General purpose coefficient 3
COEFFICIENT4 | Number |  | N | General purpose coefficient 4
COEFFICIENT5 | Number |  | N | General purpose coefficient 5
GPNUMBER1 | Number |  | N | General purpose number 1
GPNUMBER2 | Number |  | N | General purpose number 2
GPSTRING1 | Character | 20 | N | General purpose string 1
GPSTRING2 | Character | 20 | N | General purpose string 2
ALERT_ID | Number |  | N | ALERT identifier for sensor
ALERT_TYPE | Character | 10 | n | ALERT sensor type

XC_DATA1

Name | Data Type | Length | Required | Description
STATION_ID (PK) | Character | 20 | Y | Name of station where sensor is located
SENSORNAME (PK) | Character | 12 | Y | Name of sensor
TIME_TAG (PK) | Date |  | Y | Date and time sensor value received
SOURCE (PK) | Character | 1 | Y | Source of data. Valid options are: S (Self-timed), R (Random), C (Current), T (Timetag)
ORIG_VALUE | Number |  | Y | Original data value as processed by XC Rtu or XC Decode
ED_VALUE | Number |  | N | Edited data value
FLAG1 | Character | 1 | N | General purpose quality flag 1
FLAG2 | Character | 1 | N | General purpose quality flag 2
FLAG3 | Character | 1 | N | General purpose quality flag 3
FLAG4 | Character | 1 | N | General purpose quality flag 4
HIGH_HIGH_FLAG | Number |  | N | Status of high high flag. Valid options are: 0 (NORMAL), 1 (ABOVE), -1 (BELOW)
HIGH_FLAG | Number |  | N | Status of high flag. Valid options are: 0 (NORMAL), 1 (ABOVE), -1 (BELOW)
LOW_FLAG | Number |  | N | Status of low flag. Valid options are: 0 (NORMAL), 1 (ABOVE), -1 (BELOW)
LOW_LOW_FLAG | Number |  | N | Status of low low flag. Valid options are: 0 (NORMAL), 1 (ABOVE), -1 (BELOW)
ROC_FLAG | Number |  | N | Status of rate of change flag. Valid options are: 0 (NORMAL), 1 (ABOVE), -1 (BELOW)
NO_CHG_FLAG | Number |  | N | Status of no change flag. Valid options are: 0 (NORMAL), 1 (CHANGE)
ALARM_FLAG | Number |  | N | Status of alert flag. Valid options are: 0 (NORMAL), 1 (CHANGE)

XC_TXTDATA1

Name | Data Type | Length | Required | Description
STATION_ID (PK) | Character | 20 | Y | Name of station where sensor is located
SENSORNAME (PK) | Character | 12 | Y | Name of sensor
TIME_TAG (PK) | Number |  | Y | Date and time senor value received
SOURCE (PK) | Character | 1 | Y | Source of data. Valid options are: S (Self-timed), R (Random), C (Current), T (Timetag)
TEXT_VALUE | Character | 256 | Y | Original text value as received by XC Rtu or XC Decode
FLAG1 | Character | 1 | N | General purpose quality flag 1
FLAG2 | Character | 1 | N | General purpose quality flag 2
FLAG3 | Character | 1 | N | General purpose quality flag 3
FLAG4 | Character | 1 | N | General purpose quality flag 4
MESSAGE_STATUS | Character | 2 | N | Status character used to track if message has been read, forward, etc.
TXT_ALARM_FLAG | Number |  | N | Status of text alarm flag. Valid options are: 0 (NORMAL), 1 (ALARM)

XC_PPDATA1

Name | Data Type | Length | Required | Description
STATION_ID (PK) | Character | 20 | Y | Name of station where sensor is located
DATA_LABEL (PK) | Character | 20 | Y | Name of computed value
PPI_NAME (PK) | Character | 5 | Y | Name of post processing instruction
TIME_TAG (PK) | Date |  | Y | Date and time of start of the post processing time period
TIME_PERIOD (PK) | Number |  | Y | Number of hours/days of data used by function
PP_VALUE | Number |  | Y | Post processed value
FLAG1 | Character | 1 | N | General purpose quality flag 1
FLAG2 | Character | 1 | N | General purpose quality flag 2
FLAG3 | Character | 1 | N | General purpose quality flag 3
VALUE_TIME_TAG | Date |  | N | Exact time value occurred (i.e, Time of max value)
PROCESS_TIME_TAG | Date |  | Y | Date and time value was actually processed/calculated
SENSORNAME | Character | 12 | Y | Name of sensor calculations performed on
ALTERNATE_LABEL | Character | 20 | N | Alternate label for computed value

XC_GOESQC

Detailed descriptions of quality fields are in the NESDIS header topic under Advanced Topics.

Name | Data Type | Length | Required | Description
NESDIS_ID (PK) | Character | 8 | Y | NESDIS or satellite agency identifier
TIME_TAG (PK) | Date |  | Y | Date and time message was transmitted
SOURCE (PK) | Character | 1 | Y | Source of message. Valid options are: S (Self-timed), R (Random)
STATION_ID | Character | 20 | N | XConnect station name, if not defined, defaults to NESDIS ID
FAILURE_CODE | Character | 1 | N | Message status
SIG_STRENGTH | Number |  | N | Signal Strength
FREQ_OFFSET | Number |  | N | Frequency Offset
MOD_INDEX | Character | 1 | N | Modulation Index
MOD_QUAL | Character | 1 | N | Modulation Quality
CHANNEL | Number |  | N | Channel message transmitted on
SAT_LOC | Character | 1 | N | GOES satellite message transmitted to
UC_STATUS | Character | 2 | N | Uplink carrier status (NOT CURRENTLY USED - ALWAYS FF)
MESSAGE_LEN | Number |  | N | Transmitted message length
ACTUAL_LEN | Number |  | N | Actual received message length
PARITY NUMBER | Number |  | N | Number of parity characters in message
BUFFER_EMPTY | Number |  | N | Number of BUFFER EMPTY messages transmitted by station (SATLINK only)
BATTERY_VOLTAGE | Number |  | N | Battery voltage at station when message was transmitted
SPARE1 | Number |  | N | Spare field for future use
SPARE2 | Number |  | N | Spare field for future use

XC_RTUQC

Name | Data Type | Length | Required | Description
STATION_ID (PK) | Character | 20 | Y | Name of the station SSP message was transmitted/received to/from
TIME_TAG (PK) | Date |  | Y | Date and time SSP message value transmitted/received
RX_TX (PK) | Character | 1 | Y | SSP messages was transmitted or received by XConnect
PORT | Character | 30 | N | Port SSP message was sent/received (i.e., COM!, COM2....)
SEQUENCENUM | Number |  | N | Sequence/flag number used in SSP message.
OPCODE | Number |  | N | SSP operation code (CurDataReq, TimeTagReq)
STATUS | Number |  | N | Status of SSP message (0 - None, 1 - Success, 2 - Failed)
RETRIES | Number |  | N | Number of retries used
GOOD | Number |  | N | Number of good messages received by the station
BAD | Number |  | N | Number of bad messages received by the station
CRC | Number |  | N | Number of SSP messages with CRC errors received by the station
BATTERY_VOLTAGE | Number |  | N | Battery Voltage from SSP message
SPARE1 | Number |  | N | Spare field for future use
SPARE2 | Number |  | N | Spare field for future use


XML data format

The XML format we use is shown below. The layout is very straight-forward. MSXML4.0 is installed by XConnect to parse the XML output files. The root node is XC_DATA. Inside the XC_DATA node, each data record is enclosed by a DATA tag. Additional tags used are:

  • STATION_ID - This tag encloses the XConnect station name.

  • SENSORNAME - This tag encloses the XConnect sensor name

  • TIME_TAG - This tag encloses the date/time stamp of when the data was measured.

  • SOURCE - This tag encloses the source of the data. Valid options are: S (Self-timed), R (Random), C (Current), T (Timetag).

  • VALUE - This tag encloses the sensor value.

Example

<?xml version="1.0" encoding="UTF-8" ?>

- <XC_DATA>

- <DATA>

<STATION_ID>Station_1</STATION_ID>

<SENSORNAME>Sensor_1</SENSORNAME>

<TIME_TAG>2003-02-12 15:55:35</TIME_TAG>

<SOURCE>S</SOURCE>

<VALUE>0</VALUE>

</DATA>

- <DATA>

<STATION_ID>Station_2</STATION_ID>

<SENSORNAME>Sensor_1</SENSORNAME>

<TIME_TAG>2003-02-12 15:55:35</TIME_TAG>

<SOURCE>S</SOURCE>

<VALUE>0.3</VALUE>

</DATA>

- <DATA>

<STATION_ID>Station_3</STATION_ID>

<SENSORNAME>Sensor_1</SENSORNAME>

<TIME_TAG>2003-02-12 15:55:35</TIME_TAG>

<SOURCE>S</SOURCE>

<VALUE>8.6</VALUE>

</DATA>

- <DATA>

<STATION_ID>Station_4</STATION_ID>

<SENSORNAME>Sensor_1</SENSORNAME>

<TIME_TAG>2003-02-12 15:55:35</TIME_TAG>

<SOURCE>S</SOURCE>

<VALUE>2</VALUE>

</DATA>

- <DATA>

<STATION_ID>Station_5</STATION_ID>

<SENSORNAME>Sensor_1</SENSORNAME>

<TIME_TAG>2003-02-12 15:55:35</TIME_TAG>

<SOURCE>S</SOURCE>

<VALUE>2.7</VALUE>

</DATA>

</XC_DATA>


ASCII Log/EXCEL data format

The ASCII Log and EXCEL data formats are very simple. The ASCII log file is a file containing comma-separated values. The EXCEL format contains the same data as ordered in the ASCII log option but written in the native XLS format.

Format

DATA TIME,SOURCE,STATION.SENSOR,VALUE,STATION.SENSOR,VALUE,STATION.SENSOR,VALUE....

Example

12/31/1998 15:00:00,Precip,0.0,QFE,945.6,QFF,1020.2,Battery,13.8,WindDir,205.6,Humidty,50.5,PresAtm,945.6,RadSolar,784,Temp,19.2,WindSpd,2.7


Troubleshooting tips

XC Desktop's role is to allow the user to edit XConnect configuration parameters. XC Desktop is the one application where all primary XConnect modules can be configured. Stations, sensors, ports, and applications can be configured here. XC Desktop requires XC Setup to run. It is only displaying the information XC Setup holds in memory in a friendly, graphical way. If ever there seems to be a disconnect or incorrect information displayed on XC Desktop, from the main menu, select View|Refresh (F5) or press [image] on the toolbar.

Cannot save station and/or sensors to database

Database version mismatch

If this is an existing database with a recent XConnect update, the database schema may have been changes. The release notes usually notify the uses of any changes. if so, use the Table DDL utility to update the tables. Select Start|Programs|XConnect|Tools|Table DDL Utility. This application can generate new tables in a database or update existing tables.

  1. Select the ODBC Data Source configured for the database.

  2. Select the specific database: Oracle, Access, or SQL Server.

  3. Make sure the Update check box is checked.

  4. Select the [image] toolbar button to connect to the database. The application will log in the database using the Username and Password entered.

  5. Select the [image] toolbar button to update the database.

  6. Select the [image] toolbar button to disconnect from the database when finished.

INI file copied from another XConnect system

If the INI file was copied from another XConnect system and the ODBC Data source is the same name as well, the user will need to first select the Data Storage as NONE in the System Init setup window, save changes and then re-select the data source.

The reason is that the even though the data source selection was saved in the INI file, the entries in the Windows registry are incomplete. By de-selecting and re-selecting the data source, the Windows registry entries will be made.

Catastrophic Failure

If a Catastrophic Failure is received during edits in XC Desktop, the COM connection with XC Setup has been corrupted. Please close XC Desktop and XC Setup. Re-start XC Desktop.


Error messages

Troubleshooting steps:

Reasons for error:

  • User name is not configured for read/write privilege.

Return to XC Desktop to configure user privileges.

Troubleshooting steps:

Ensure that:

  • User name and password are entered correctly.

  • Caps lock key is on (User name and passwords are case-sensitive).

Troubleshooting steps:

Potential reasons for error:

  • Application on Run parameter line does not exist.

Make sure the correct path and name are typed (i.e. c:\myapp\mynewapp.exe)

  • First application on Run parameter is run but others are not.

If all paths and filenames are correct, make sure each application name is separated by a comma only and not a comma and space.

Troubleshooting steps:

A COM interface connection is made by each XConnect application to XC Setup. This allows the applications to retrieve and send configuration parameters related to XC Mux.

Potential reasons for error:

  • XC Setup is not running.

Close current application and restart. XC Setup should start automatically.

  • XC Setup does not start automatically with XConnect application.

Close current application. Start XC Setup manually from Start Menu. Then re-start XConnect application.

If error still persists, reboot computer.

Troubleshooting steps:

XC Setup must be running for all other XConnect applications to function properly. Various parameters are retrieved and stored by the XConnect applications.

Each XConnect application will attempt to start XC Setup if it is not running.

Ensure that:

  • XC Setup (XCSetup.exe) is in XConnect home directory.

Using Windows Explorer or My Computer, ensure that XC Setup was not accidentally deleted from the XConnect install directory. If not present, insert XConnect installation CD to repair.

Troubleshooting steps:

Potential reasons for error:

  • XC Setup is not running.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close current application and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Setup is not running.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close current application and re-start.

Troubleshooting steps:

Ensure that:

  • Current XConnect application is part of the purchased XConnect license.

Refer to the original purchase order.

Troubleshooting steps:

Potential reasons for error:

  • Current XConnect application is not valid for use with existing XConnect license.

Call Sutron Sales to upgrade XConnect license.

Troubleshooting steps:

Ensure that:

  • XC Desktop was unable to create the binary data file in the specified directory.

Verify the data file name, description and sensor selection.

Troubleshooting steps:

The data storage option selection is invalid with the XConnect installation. Potential reasons for error:

  • XConnect Lite was purchased. The database data storage option is an invalid option for XConnect Lite.

Troubleshooting steps:

Potential reasons for error:

  • XC Setup is not running.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close current application and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Setup is not running.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close current application and re-start.

Troubleshooting steps:

Potential reasons for error:

  • For Excel/ASCII log file storage option, an error in the file directory will prevent the creation of the data storage option.

Using Windows Explorer, ensure the file directory exists and can be viewed.

  • For PcBase2 binary file and database storage option, a memory error will prevent the creation of the data storage option.

Close all unnecessary applications and XConnect modules and re-start XConnect. If error continues after re-start of XConnect, re-boot computer.

Troubleshooting steps:

For the PcBase2 binary file data storage option, XC Decode and XC Desktop must read the header of every binary file in the XConnect system.

Potential reasons for error:

  • Binary file may be corrupt.

Recreate data file in XC Desktop or contact Sutron Customer service for additional assistance.

Troubleshooting steps:

Potential reasons for error:

  • PcBase2 binary file may be corrupt.

Try to re-select the binary file or contact Sutron Customer service for additional assistance.

  • Insufficient disk space to store data.

Open My Computer. Right click on the properties of the drive (i.e., C:) that XConnect is installed. Check disk space used.

Troubleshooting steps:

For the PcBase2 binary file data storage option, XC Decode must read the header of every binary file in the XConnect system to properly initialize the data storage option.

Potential reasons for error:

  • Binary file may be corrupt.

Try to re-select the binary file or contact Sutron Customer service for additional assistance.

Delete or deactivate corrupt binary data file. Recreate binary data file in XC Desktop.

Troubleshooting steps:

For the database storage option and the current XConnect database schema, this error should never occur.

If the XConnect database schema expands to include multiple XC_DATA tables (i.e, XC_DATA1, XC_DATA2...etc), the sensor records in XC_SITESSENSORS will contain which data table the specific sensor is stored.

Troubleshooting steps:

For the PcBase2 binary file data storage option, after decoding the sensor, XC Decode must then determine which binary file to store the data.

Potential reasons for error:

  • Ensure sensor is assigned to a binary data file.

Verify sensor is selected to be stored in one of the binary data files.

Troubleshooting steps:

For the database storage option and the current XConnect database schema, this error should never occur.

If the XConnect database schema expands to include multiple XC_DATA tables (i.e, XC_DATA1, XC_DATA2...etc), the sensor records in XC_SITESSENSORS will contain which data table the specific sensor is stored.

Troubleshooting steps:

Potential reasons for error:

  • Verify file selected is an XConnect INI file

Many applications use INI files to hold startup information. Open the INI file in notepad and verify the contents are XConnect related.

  • XC Setup is not running.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close current application and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Setup was loading a large INI file.

Wait a moment and select the Refresh (F5) option.

  • XC Setup is not running.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close current application and re-start.

Troubleshooting steps:

Potential reasons for error:

  • COM connection to XC Setup may be faulty. Close current application and re-start.

Ensure that XC Setup is shown on the Windows taskbar.

Troubleshooting steps:

Potential reasons for error:

  • COM connection to XC Setup may be faulty. Close current application and re-start.

Ensure that XC Setup is shown on the Windows taskbar.

Troubleshooting steps:

Potential reasons for error:

  • COM connection to XC Setup may be faulty. Close current application and re-start.

Ensure that XC Setup is shown on the Windows taskbar.

Troubleshooting steps:

Potential reasons for error:

  • COM connection to XC Setup may be faulty. Close current application and re-start.

Ensure that XC Setup is shown on the Windows taskbar.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop is experiencing problems.

Wait a moment and select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop is experiencing problems.

Wait a moment and select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop is experiencing problems.

Wait a moment and select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop is experiencing problems.

Wait a moment and select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop is experiencing problems.

Wait a moment and select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop is experiencing problems.

Wait a moment and select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Ensure that:

  • In the System Init setup window, check whether this XConnect system is a conventional or satellite system.

XC Desktop will not allow a com port to be created if neither of these options are selected.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Close XC Desktop and re-start.

  • Unable to allocate memory for new node.

Close XC Desktop and re-start.

Close XC Setup and re-start.

Re-boot system and re-start XC Desktop.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Close XC Desktop and re-start.

  • Unable to allocate memory for new node.

Close XC Desktop and re-start.

Close XC Setup and re-start.

Re-boot system and re-start XC Desktop.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Close XC Desktop and re-start.

  • Unable to allocate memory for new node.

Close XC Desktop and re-start.

Close XC Setup and re-start.

Re-boot system and re-start XC Desktop.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Close XC Desktop and re-start.

or

Delete current station and add new station.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Close XC Desktop and re-start.

or

Delete current sensor and add new sensor.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Close XC Desktop and re-start.

or

Delete current com port and add new com port.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Potential reasons for error:

  • Setup filename cannot be empty.

Please select a valid setup file (.SET/.SSF) to import.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to communicate with XC Setup. COM connection to XC Setup may be corrupted.

Select the Refresh (F5) option.

Close XC Desktop and re-start.

Troubleshooting steps:

Potential reasons for error:

  • When copying and pasting com port setup parameters, you can only perform this action with the same com port types. For example, direct com port parameters can only be pasted on to another com port created as a Direct type.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to read the header of the binary data. The header contains the list of sensors in the data file, the start date of the data, the interval of the data and the data file description.

Try to view the data in XC DataView. If that fails, the binary file is probably corrupt.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to retrieve the data source user name and password settings from the registry.

Ensure that the Windows user logged in that configured the data source, user name and password had write privileges to the registry. The source name, user name and password are stored in the registry.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to write the data source user name and password settings from the registry.

Ensure that the Windows user logged in has write privileges to the registry. The source name, user name and password are stored in the registry.

Troubleshooting steps:

Potential reasons for error:

  • Error occurs when XC Desktop is saving sensor setup parameters. As a part of the validation process, the sensors in the Raw List are validate. The sensors must exist.

Verify the sensors in the Raw List are defined in XConnect.

Troubleshooting steps:

Potential reasons for error:

  • Error occurs when XC Desktop is saving sensor setup parameters. As a part of the validation process, the sensors in the Raw List must be the same type the sensor. If the sensor is a text (Is Text flag checked), the sensors in the Raw List must also be text also.

Verify the sensors in the Raw List match the current sensor with respect to the state of the Is Text flag.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop tried to send the validated station setup parameters to XC Setup. An error occurred while trying to send the parameters via COM.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close applications and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was not able to execute the SQL statements to insert or update the station setup parameters.

If using Access as your database, make sure the file or data tables are not open.

If using other database, verify database access is functioning properly using XC Reports or consult your database administrator.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop tried to send the validated sensor setup parameters to XC Setup. An error occurred while trying to send the parameters via COM.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close applications and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was not able to execute the SQL statements to insert or update the sensor setup parameters.

If using Access as your database, make sure the file or data tables are not open.

If using other database, verify database access is functioning properly using XC Reports or consult your database administrator.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop tried to send the validated sensor setup parameters to XC Setup. An error occurred while trying to send the parameters via COM.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close applications and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop tried to send the validated com port setup parameters to XC Setup. An error occurred while trying to send the parameters via COM.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close applications and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop tried to send the validated mux setup parameters to XC Setup. An error occurred while trying to send the parameters via COM.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close applications and re-start.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop tried to send the validated poll group setup parameters to XC Setup. An error occurred while trying to send the parameters via COM.

Ensure that XC Setup is shown on the Windows taskbar.

  • COM connection to XC Setup is corrupted. Close applications and re-start.

Troubleshooting steps:

Potential reasons for error:

  • Sensor name exists. XConnect does not allow duplicate sensor names for a station.

Please enter a unique sensor name for the station.

Troubleshooting steps:

Potential reasons for error:

  • Station name exists. XConnect does not allow duplicate station names, RTU Unit IDs or satellite IDs.

Please enter a unique station name, RTU Unit ID or satellite ID.

Troubleshooting steps:

Potential reasons for error:

  • Station name exists. XConnect does not allow duplicate station names, RTU Unit IDs or satellite IDs.

Please enter a unique station name, RTU Unit ID or satellite ID.

Troubleshooting steps:

Potential reasons for error:

  • As dictated by the satellite agency, the satellite identifier must be 8 characters in length.

Troubleshooting steps:

Potential reasons for error:

  • Station name exists. XConnect does not allow duplicate station names, RTU Unit IDs or satellite IDs.

Please enter a unique station name, RTU Unit ID or satellite ID.

Troubleshooting steps:

Potential reasons for error:

  • Part of the process in saving the database data storage option parameters is not only verifying a database connection, but also checking for the correct data table structure.

Verify the Data Source (ODBC) settings for XConnect database.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to save user changes to binary data file. Binary file may be corrupt.

Verify binary data file in XC DataView.

or

Delete binary data file and re-create.

Troubleshooting steps:

Potential reasons for error:

  • Parameters are checked for errors before saving changes.

Resolve any errors flagged on the Station setup window.

Troubleshooting steps:

Potential reasons for error:

  • Parameters must be validated before they can be copied.

Resolve any errors flagged on the Station setup window.

Troubleshooting steps:

Potential reasons for error:

  • XC Desktop was unable to login to the database source before saving parameters.

Verify the user name and password is entered correctly on the Data Storage setup window.

Verify the Data Source (ODBC) is configured correctly. Consult your network administrator for assistance.

Troubleshooting steps:

Ensure that:

  • Only a file path is required, without a filename. This parameter only requires a directory location.

Troubleshooting steps:

Potential reasons for error:

  • File selected has an INI extension.

If you know the contents of the file are XConnect settings, open Windows Explorer and rename the file extension to INI.

Troubleshooting steps:

Ensure that:

  • Parameter must be at least 6 characters long.

Troubleshooting steps:

Potential reasons for:

  • XC Desktop was attempting to read the user settings in the registry.

The registry key settings for the user does not exist so the update cannot occur. This error is unlikely.

Troubleshooting steps:

Potential reasons for:

  • XC Desktop was attempting to update the user settings in the registry.

The registry key settings for the user does not exist so the update cannot occur. This error is unlikely.

  • Windows user does not have privileges to open and edit the registry.

The Windows login user does not have the windows privileges to update registry. Consult your network administrator to modify user privileges.

Troubleshooting steps:

Potential reasons for error:

  • Station or sensor has already been designated as a sensor.

Click and expand on the Users node of the system tree view to see current stations or sensors designated as templates.

Troubleshooting steps:

Ensure that:

  • XC Rtu is installed and in the XConnect directory.

Open Windows Explorer and click on the XConnect installation directory. Verify XCRtu.exe is listed.

Troubleshooting steps:

Ensure that:

  • XC Decode is installed and in the XConnect directory.

Open Windows Explorer and click on the XConnect installation directory. Verify XCDecode.exe is listed.

Troubleshooting steps:

Potential reasons for error:

  • Station was saved in XConnect but not saved to database.

Return to Station Setup window and save parameters. Save changes to XConnect and then click OK when prompted to save to database.

  • Data storage option was changed to database.

From the XC Desktop main menu, select Tools|Save All to Database. This will automatically create all stations and sensors in the database selected in the Data Storage setup window.

  • Upgrading to XConnect and starting with PcBase2.ini.

From the XC Desktop main menu, select Tools|Save All to Database. This will automatically create all stations and sensors in the database selected in the Data Storage setup window.

Troubleshooting steps:

Ensure that:

  • Database connection is functioning. SQL command failed.

If database is on network computer, verify network is functioning properly.

If database is an Access file, verify the file is not open or has not been moved from its expected directory location.

Troubleshooting steps:

Ensure that:

  • Database connection is functioning. SQL command failed.

If database is on network computer, verify network is functioning properly.

If database is an Access file, verify the file is not open or has not been moved from its expected directory location.

Troubleshooting steps:

Ensure that:

  • Currently, only one com port can be defined as a DDRGS port.

Delete the first DDRGS port and then create the new one.

Troubleshooting steps:

Potential reasons for error:

  • While trying to import the 8200/8210 setup, an invalid format was encountered.

Setup file may be corrupt.

Troubleshooting steps:

Potential reasons for error:

  • While trying to import the 8200/8210 setup, invalid items were encountered.

Setup file may be corrupt. Carefully review station and sensor settings that have been imported.

Troubleshooting steps:

Potential reasons for error:

  • User cannot select 100-BPS DDRGS or HDR DDRGS if system is designated as a conventional system. Valid options are: Direct, Radio, Modem or Virtual.

Go to System Init setup window to change system to a satellite system.

XConnect systems can be hybrid: containing both satellite and conventional telemetry. Check all the boxes that apply to your system.

Troubleshooting steps:

Potential reasons for error:

  • User cannot select Direct, Radio, Modem or Virtual if system is designated as a satellite system. Valid options are: 100-BPS DDRGS or HDR DDRGS.

Go to System Init setup window to change system to a conventional system.

XConnect systems can be hybrid: containing both satellite and conventional telemetry. Check all the boxes that apply to your system.

Troubleshooting steps:

Ensure that:

  • Database connection is functioning.

If database is on network computer, verify network is functioning properly.

If database is an Access file, verify the file is not open or has not been moved from its expected directory location.

Troubleshooting steps:

Ensure that:

  • Database connection is functioning.

If database is on network computer, verify network is functioning properly.

If database is an Access file, verify the file is not open or has not been moved from its expected directory location.

Troubleshooting steps:

Ensure that:

  • No Change Interval parameter on Sensor Database parameters window is a number.

Troubleshooting steps:

Potential reasons for error:

  • No modem was selected from the Modem list box on the Com Port window. Parameters cannot be saved.

Select the appropriate modem for the modem port type.

Troubleshooting steps:

Potential reasons for error:

  • No com port was selected from the Port list box on the Com Port window. Parameters cannot be saved.

Select the appropriate com port number for the com port type selected.

Troubleshooting steps:

Potential reasons for error:

  • User is trying to assign a sensor template to a station.

Select another template derived from a station. Station templates will have then form of station.sensor (the name will contain a period).

Troubleshooting steps:

Potential reasons for error:

  • User is trying to assign a station template to a sensor.

Select another template derived from a sensor.

Troubleshooting steps:

Ensure that:

  • The node selected is a computer node and not a workgroup or provide or printer node.

Troubleshooting steps:

Ensure that:

  • The station name is not New Station. New Station is reserved by XC Desktop as the default station name.

Troubleshooting steps:

Ensure that:

  • The sensor name is not New Sensor. New Sensor is reserved by XC Desktop as the default sensor name.

Troubleshooting steps:

Ensure that:

  • Sensors are required for this parameter/operation. Please select a sensor(s).

Troubleshooting steps:

Ensure that:

  • Station/sensor does not exist.
  • Data storage option is NOT database. Stations and sensors cannot be renamed when database is selected

Temporarily select NONE as the data storage option, then rename the station/sensors. This will rename the station/sensor in the INI file. Re-select the database as the data storage option and save the station to the database. Note, this does not delete the record from the database of the original station/sensor.

Troubleshooting steps:

Ensure that:

  • Database connection is valid.
  • Review the ODBC error message displayed to help troubleshoot the database problem.

Troubleshooting steps:

Ensure that:

Troubleshooting steps:

Ensure that:

  • Logging ID appears in the combo-box.

If the combo-box is blank, then select the combo-box and right click. Select New. Enter the Logging ID. For 8200/8210, enter 0. For the 9210/XPert, enter Logging ID used in the EZSetup.

Error messages

Potential error messages generated by XC Desktop during configuration are:

Error 1: User does not have correct privileges to perform action.

Error 2: Invalid user/password settings.

Error 3: Unable to run - xxx.

Error 4: An instance of the "XCSetup.Applications" OLE Automation class could not be created. Is XC Setup running?

Error 5: XC Setup is not running. Process halted.

Error 6: An error occurred while retrieving parameters from XCSetup.

Error 7: Unable to retrieve General Setup parameters.

Error 8: Invalid License Key. Please verify XConnect is properly installed.

Error 9: Invalid License Key. Exiting now...

Error 102: Unable to create xxx.dat.

Error 600: Data storage option invalid with XConnect installation.

Error 601: Unable to retrieve Data Storage Setup parameters.

Error 602: Unable to update Data Storage Setup parameters.

Error 603: Unable to create data store option.

Error 604: Unable to read header from file xxx.

Error 607: Unable to write data for file xxx.

Error 610: Unable to open all data files.

Error 620: Unable to locate station.sensor in database.

Error 621: No data file found to store station.sensor.

Error 622: No data table found to store station.sensor.

Error 900: Unable to retrieve INI information from XC Setup.

Error 901: Unable to load INI file information from XC Setup.

Error 902: COM Data request for Station List Details failed for station.

Error 903: COM Data request for Mux Port List Details failed for comx.

Error 904: COM Data request for Rtu Com Port List Details failed for comx .

Error 905: COM Data request for PollGroup Details for Pollgroup: xx.

Error 906: Unable to update Station list view.

Error 907: Unable to update Mux Port list view.

Error 908: Unable to update Rtu Port list view.

Error 909: Unable to update PollGroup list view.

Error 910: Unable to update list view.

Error 911: Unable to update Users list view.

Error 912: Unable to add COM port. Go to System Init to specify RTU or MUX system.

Error 913: Unable to add new xxx.

Error 914: Unable to add new sensor.

Error 915: Unable to add new Decoding scheme for Sensor xxx.

Error 916: Unable to rename station.

Error 917: Unable to rename sensor.

Error 918: Unable to rename com port.

Error 919: Unable to delete xxx.

Error 920: Please assign a Setup File name.

Error 921: Unable to delete Sensor Decode Setup parameters.

Error 922: Unable to paste onto different type of COM setups.

Error 923: Unable to read Binary data file information.

Error 924: Unable to retrieve XConnect database settings.

Error 925: Unable to update XConnect database settings.

Error 926: Raw list sensor xxx is invalid.

Error 927: Raw list sensor xxx has Is Text checked where xxx is a number. Raw list sensors must be same type as sensor.

Error 928: Unable to update Station Setup parameters.

Error 929: Unable to save Station parameters to Database.

Error 930: Unable to update Sensor Setup parameters.

Error 931: Unable to save Sensor parameters to Database.

Error 932: Unable to update Sensor Decode Setup parameters.

Error 933: Unable to update Com Port Setup parameters.

Error 934: Unable to update Mux Port Setup parameters.

Error 935: Unable to update Poll Group Setup parameters for pollgroup xxx.

Error 936: Sensor already exists. Please assign another name for the sensor.

Error 937: Station already exists. Please assign another name for the station.

Error 938: Unit ID xxx already exists for station xxx. Please assign another Unit ID for the station.

Error 939: Satellite ID must be 8 characters.

Error 940: Satellite ID xxx already exists station xxx. Please assign another Satellite ID for the station.

Error 940: Unable to verify XConnect tables in xxx database.

Error 941: Unable to save changes to the datafile xxx.dat.

Error 942: Unable to save changes. Invalid parameters.

Error 943: Unable to copy parameters. Invalid parameters.

Error 944: Unable to connect to database. Please go to <Data Storage Systems> to verify database settings.

Error 945: Please specify only a file path with no filenames.

Error 946: Please select a valid INI file.

Error 947: Minimum 6 characters required.

Error 948: Unable to retrieve User login settings from registry.

Error 949: Unable to update User login settings in registry.

Error 950: xxx is already a template.

Error 951: Unable to start XC Rtu.

Error 952: Unable to start XC Decode.

Error 953: Station is not configured in database. Please go to <Station Setup> window and save station to database.

Error 954: Unable to save station parameters for station to database.

Error 955: Unable to save sensors parameters for station.sensor to database.

Error 956: Mux Port has already been defined. Unable to create another port.

Error 957: Invalid setup. Import failed.

Error 958: Unable to read setup file.

Error 959: Unable to assign xxx type for COM port. Conventional system selected in <System Init>.

Error 960: Unable to assign xxx type for COM port. Satellite system selected in <System Init>.

Error 961: Unable to retrieve database parameters.

Error 962: Unable to save database parameters.

Error 963: Invalid No Change Interval day value.

Error 964: No modem has been selected.

Error 965: No com port has been selected.

Error 966: Unable to assign sensor template to station.

Error 967: Unable to assign station template to sensor.

Error 968: Please select a valid computer node.

Error 969: Station name cannot be XC Desktop default station name.

Error 970: Sensor name cannot be XC Desktop default sensor name.

Error 971: No sensors have been selected.

Error 972: Cannot rename station/sensor when data storage is database.

Error 973: Unable to save station parameters for station to database - ODBC error msg. Do you want to continue saving to DB?

Error 974: Unable to save sensors parameters for station.sensor to database - ODBC error msg. Do you want to continue saving to DB?

Error 975: Logging ID is blank. Select New to create Logging ID first.

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Assign template

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Data storage window

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Import setup window

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


List or Parameter window

List/Setup View window

This section of XC Desktop has a dual role. It displays a list of items when a main branch of the System tree is selected or will display the appropriate setup window for the sub branch/node selected.

As an example, if the Stations node is selected, then a list of all stations and their details will be displayed. If a Station is selected, the Station setup window will replace the list view.


Menu bar

The Menu Bar

The Menu Bar provides access to the following menus:

File

  • New Settings -- opens a different XConnect INI file.

  • Save Settings -- saves current settings/parameters to INI file.

  • Startup -- automatically starts XConnect applications designated in System Init (i.e., XC Rtu, XC Decode).

  • Shutdown -- signals XC Setup to send a shutdown command to XConnect data collection servers such as XC Rtu, XC Decode, XC Daps and XC Mux. XC Setup will not shut down since XC Desktop is still running.

  • Connect -- connects XC Desktop to remote XC Setup.

  • Refresh -- sends an application Refresh message all applications (other XConnect programs and other client programs) connected to XC Setup instructing them to flush their local buffers and reload the latest setup information from XC Setup.

  • ReInitialize -- sends an application ReInitialize message to all applications (other XConnect programs and other client programs) connected to XC Setup controlling or using communcations ports (XC Mux and XC Rtu). Applications are instructed to flush their local buffers, reload the latest setup information from XC Setup and Reinitialize the communication ports by releasing the com port and opening it with new port parameters.

  • Login -- user login for XConnect system.

  • Exit -- terminates the application.

Edit

  • Copy -- copies highlighted text to Windows clipboard.

  • Paste -- pastes contents of Windows clipboard.

  • Copy Params -- copies current setup parameters (applies only to station setup and sensor setup parameters).

  • Paste Params -- pastes setup parameters t(applies only to station setup and sensor setup parameters).

  • Restore Params -- restores setup parameters prior to user edits.

View

  • Large Icons -- displays items by using large icons.

  • Small Icons -- displays items by using small icons.

  • List -- displays items in a list.

  • Details -- displays items in a list with information about each item.

  • Refresh -- refreshes XC Desktop display by re-retrieving parameters from XC Setup.

  • Expand Tree -- expands to all sub-nodes of System Tree.

  • Collapse Tree -- displays only major modes of System Tree.

Tools

  • New/Add -- adds a new item (i.e., station, sensor, pollgroup, or communication port).

  • Add Sensor -- adds a new sensor if user is on Station Setup window.

  • Delete -- deletes item (i.e., station, sensor, pollgroup, or communication port).

  • Save Changes -- saves user changes.

  • Save Database Changes -- if database storage option selected, saves station or sensor setup to database.

  • Save All to Database -- if database storage option selected, automatically saves all station and senors to database.

  • Assign Template -- assigns a template to the current station or sensor.

  • Unassign Template -- unassigns template from current station or senor.

  • Make Template -- makes this station or sensor available to be used as a template.

Import

  • RTU Setup -- imports a RTU setup and automatically create the station and sensors in XC Desktop.

Help

  • XC Desktop Help -- accesses this help system and defaults to Index tab.

  • XC Desktop Contents -- accesses this help system and defaults to Contents tab.

  • About -- gets version information for this application.


New Comport

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


New comport prompt

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


New Pollgroup

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


New Sensor

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


New Station

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


New user

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Selecting RTU setup file

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Sensor setup

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Station setup

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


Status Bar

The Status Bar

The Status Bar is divided in three sections. The left-hand panel displays the user logged in and his/her privileges. The middle panel displays parameter hints. The right-hand panel displays station or sensor template information, if applicable.

If no users are defined, the user logged in will be NONE and the privileges will be FULL. As soon as a user is defined in XC Desktop, the user and privileges displayed will be NONE and NONE.


System Init window

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


System Tree

The System Tree

The System Tree provides the user with a quick way to view and navigate through their XConnect system. The main branches/nodes of the tree are:

  • Stations - this branch lists the station and sensors defined in the system.

  • Communication Ports - this branch lists the communication ports used in the system.

  • Poll Groups - this branch list the polling groups used by a conventional system.

  • Conventional Systems - this branch lists the applications used in a conventional system.

  • Satellite Systems - this branch lists the applications used in a satellite system.

  • Data Storage Systems - this branch shows the setup window for configuring data storage.0

  • System Init - this branch shows a setup window for system initialization.

  • Templates - this branch lists the stations or sensors assigned as templates.

  • Users - this branch list the users defined in the XConnect system.


Toolbar

The XC Desktop Toolbar

The toolbar area allows you to quickly access various XC Desktop functions.

The following tools are provided:

Automatically start XConnect applications designated in System Init (i.e., XC Rtu, XC Decode).

Signal XC Setup to send a shutdown command to XConnect data collection servers such as XC Rtu, XC Decode, XC Daps and XC Mux. XC Setup will not shut down since XC Desktop is still running.

Connect XC Desktop to remote XC Setup.

Reinitialize application. Flush local buffers and reload the latest setup information from XC Setup. Additionally, applications such as XC Rtu or XC Mux will release their ports, obtain new port information and re-open the port.

Copies highlighted text to Windows clipboard.

Pastes contents of Windows clipboard.

Copies current setup parameters (applies only to station setup and sensor setup parameters).

Pastes setup parameters (applies only to station setup and sensor setup parameters).

Add a new item (i.e., station, sensor, pollgroup, or communication port).

Deletes item (i.e., station, sensor, pollgroup, or communication port).

Save user changes.

If database storage option selected, save station or sensor setup to database.

Import a RTU setup and automatically create the station and sensors in XC Desktop.

Refreshes XC Desktop display by re-retrieving parameters from XC Setup.

Allows user to view items using as large icons, small icons, list or detail list.

Open the on-line help (this document).


XC Daps setup window

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


XC Decode setup window

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


XC Mux setup window

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.


XC Rtu setup window

Copyright © 2003 - 2006 Sutron Corporation. All rights reserved.