sutron standard format - division of nearshore...

TIDE STATION USERS’ MANUAL Appendix A 1

APPENDIX AGOES TRANSMISSION

FORMATTING

Appendix A covers: Setting up the NOSGOESFormat.txt file

Content and control of the Ports Tag and

Table-controlled dial-in reports

Sutron Corporation 21300 Ridgetop Circle Sterling, VA 20166 USA (703)406-2800 www.sutron.com


1 NOS GOES TRANSMISSION FORMATTING

1.1 BACKGROUND

The NOS GOES data transmission format has been under development and refinement since June of 2001. Sutron has worked closey with NOS personnel to provide a formatter that supports the traditional 3-hour GOES transmissions as well as the new 6-minute interval transmissions. Sutron has also worked with NOS to support the traditional “Ports Tag” dial in report as well as a new user-controlled dial-in report.

Controlling the format of NOS GOES transmissions is done by setting up a text table that is loaded into the XPert. The table allows you to change the content and formatting of the GOES message without making changes to the actual XPert software. The XPert encodes data according to the contents of an ASCII table that isread in by the XPert when recording is turned on. Thus, the GOES message can be modified at any time within the limits set by the table design. The parameter code mapping afforded by the table also applies to the Ports Tag report. A second dial-in report, similar in nature to the Ports Tag report, with contents and sequencing set by the table, is also included.

During the fall of 2003, NOS carried out experiments to determine the feasibility of transmitting tide data every six minutes on the GOES self-timed channels. These experiments resulted in several additions to the formatter including:

A new message header to distinguish the 6-minute transmissions

Water level encoding as 3-byte means with no scaling

Some changes to the overall message structure to eliminate unnecessary time blocks

Changes in the handling of redundant data

1.2 PURPOSE AND SCOPE

If you select NOS as the transmission format for your GOES data you MUST have a file called NOSGOESFormat.txt on your flash disk. Data will not be transmitted at all if the file is missing. Data will not be formatted properly unless the contents of the file match the sensor setup in the XPert’s .SSF setup file.

The purpose of this appendix is to document the use of the NOSGOESFormat.txt file.

This document contains:

Description of the format control file and how it controls the GOES format and the two dial-in reports

Instructions for setting up and using the file

Information on troubleshooting



2 NOSGOESFORMAT.TXT PROPERTIES

2.1 FILE NAME AND LOCATION

The format control file is named:

NOSGoesFormat.TXT

This file must be saved in the XPert \\Flash Disk folder.

NOTE: If you select NOS as the GOES self-timed format and the format control fileis missing, YOU WILL NOT GET ANY GOES TRANSMISSIONS. Thisis true no matter how the remainder of the XPert is set up.

2.2 OVERALL APPEARANCE AND REQUIREMENTS

The format control table is actually entered into the XPert as a file containing lines of comma-separated variables. This is done for ease of coding. The table can be created as an actual table in a word processor or as cells in a spreadsheet and then saved as a .TXT file. (This may require a “Convert Table to Text” step in the word processor.)

The following is a typical format control table as stored on the XPert.

Sequence #.,Description, DPAS Code, Flag, log label, #ST, #RR, Format, Aux1, Aux2, Aux3, Aux4 1,Aquatrak, A, 1, PWL, 10, 3, AQUATRAK, PWLSIG, PWLOUT, AQT1, AQT22,Backup WL, B, ", BWL, 10, 3, MSO, BWLSIG, BWLOUT



Here is how a complex table might appear in a word processor before converting to CSV text form.

Seq. # Description DPAS

Code Flag Log label #ST #RR Format Aux1 Aux2 Aux3 Aux4

1 Aquatrak A 1 PWL 10 3 AQUATRAK PWLSIG PWLOUT AQT1 AQT2

6 Backup WL B " BWL 10 3 MSO BWLSIG BWLOUT

2 Windbird C 3 WS 10 3 WSWDG WD WG

3 Air temperature D 4 AT 10 3 SVS

4 Water temperature E 5 WT 10 3 SVS

5 Barometer F 6 BP 10 3 BAROM

0 Conductivity G 7 COND 10 3 M

7 Rainfall x : RAIN 10 3 M

8 Solar x ; SOLAR 10 3 M

0 Analog1 x < AN1 10 3 SVS

0 Analog2 x = AN2 10 3 SVS

9 Paros 1 N % PAR1 10 3 MSO PAR1SIG PAR1OUT

10 Paros 2 P & PAR2 10 3 MSO PAR2SIG PAR2OUT

0 Frequency x + FREQ 10 3 M

The format control table is composed of records (lines). A table must, at a minimum, contain TWO records – a header record and a control record. Each line must contain a certain number of fields (data items). The structure of the records and the required fields are described in the following paragraphs.

2.3 THE TABLE RECORDS

2.3.1 HEADER RECORD

The first line of the table is a header record. This record is mandatory. The contents of this record are used by the XPert to determine the type of GOES message header for NOS format transmissions. With the exception of the header selection (explained shortly), the content of the header record is arbitrary. The following is the recommended content. By maintaining this format, the user can easily identify the fields within each record.

Sequence #,Description, DPAS Code, Flag, log label, #ST, #RR, Format, Aux1, Aux2, Aux3, Aux4



The default message header for the NOS GOES transmissions is the “N” header. This header has been in use for over 15 years, and, as the name implies, starts with an ASCII N. The six-minute transmission header is referred to as the “P” header. The P header is shorter, and begins with ASCII P.

The 6-minute P header is selected by appending the string

/Header=P

to the header record, as illustrated here:Sequence #,Description, DPAS Code, Flag, log label, #ST, #RR, Format, Aux1, Aux2, Aux3, Aux4/Header=P

The / character alone will trigger the P header, but including the rest of the string is good practice so that the intent of the / is clear.

2.3.2 CONTROL RECORDS

Lines two through “n” of the file actually control the GOES format and the contents of the two Ports Tag reports. The value “n” may be as large as 30. Actual control is accomplished through the entries made for each field within the record. The purpose of the fields is described in the next section.

2.4 THE TABLE FIELDS

Each record may contain from 8 to 12 fields. The number of fields is determined by the contents of the FORMAT field. The reason for this will become clear as the fields are explained. The fields must be separated by a single comma. No comma should be placed after the last field.

2.4.1 SEQUENCE NO.

This field is used only by the Table-Controlled dial-in report. It determines the order in which information is presented in the report. A zero ( 0 ) in this column indicates that the line is NOT used in the report.

NOTE: The zero is mandatory for an unused line. Do NOT simply enter adjacent commas.



2.4.2 DESCRIPTION

The Description field is a general purpose field where the user can describe the sensor being formatted by the particular record. The description can be any ASCII text.

NOTE: DO NOT PUT EXTRA COMMAS in the text. Any comma will be viewed by the formatter as a field separator.

2.4.3 DPAS CODE

DPAS Codes are used by NOS to identify certain types of sensors and data. The example table in Section 3.2 identifies all of the currently used DPAS codes. These codes ARE NOT USED by the formatter at this time. They are in the table for future use. As such, the user can enter any ASCII value for a DPAS code. It is recommended, however, that the codes from the example table be used. If no DPAS code is assigned then use a lower-case x.

2.4.4 FLAG

The Flag field is the NOS GOES format flag for particular sensors. The Flag field IS used by the formatter and correct operation of the NOS Ports Tag report depends on the Flag field being set to the proper value. The example table in Section 3.2 lists all of the currently used GOES flags.

2.4.5 LOG LABEL

The Log Label field is used by the formatter to determine what values to encode for each flag. A single flag may be associated with more than one encoded value. For example, it is standard practice to encode the mean, standard deviation, outlier count, and two temperatures for an Aquatrak water level sensor. All the encoded values are preceded by an ASCII one ( 1 ) flag in the message. The Log Label is used to identify the FIRST, or primary value to encode in a group of values. The values to encode for the remaining items, if any, are determined by the FORMAT field and the contents of the AUXn fields.

2.4.6 #ST

This is the number of values or value groups to encode behind a single flag for a GOES self-timed message. Only two options are possible – one ( 1 ), or ten ( 10 ). The formatter makes only limited use of this field. A value of one can be used to override an XPert setup that saves 10 values per hour. A value of 10 WILL NOT override a setup that specifies one per hour.

2.4.7 #RR

This value is defaulted to three in the examples. At the current time, this field is NOT used by the formatter.



2.4.8 FORMAT

The FORMAT field determines how data for a particular sensor is encoded in the GOES message. Formats are specified by keywords plus modifiers. The combinationation of keywords and modifiers provides for encoding:

Several specific sensor types

Time blocks

Values with and without scaling for compression (water levels)

Values as either two or three bytes

The basic layout of a format specifier is:

[leading modifier]Keyword[trailing modifier]

2.4.8.1 Keywords

Keywords specify how data are to be encoded. Keywords include:

Scaled formats for water levels

Unscaled formats for general use

Unscaled and offset formats for ancillary sensors such as temperature and wind speed/direction

The scaled water level formats are:

AQUATRAK – encodes an offset, and sets of values for the water level mean, standard deviation, outlier count, and two temperatures

MSO – encodes an offset, and sets of values for the water level mean, standard deviation, outlier count

M – encodes an offset, and sets of values for the water level mean

The uscaled formats are:

SV encodes values, each as two-byte (SV) or 3-byte (SV3), pseudo-binary digits, without consideration for negative values

SVS – encodes values, each as two-byte(SV) or 3-byte (SV3), pseudo-binary digits, in two’s-compliment

The ancillary sensor formats are:

WSWDG – Wind Speed, Wind Direction, Gust – encodes sets of values for wind speed, direction, and gust

BAROM – This format is the same as SV but subtracts 800 from each value before encoding. (Assumption is that pressure is measured in mill bars.)

Several of the format require that values be placed in the AUX1 through AUX4 fields. The use of these fields is described in the next paragraph.



The amount of data encoded depends on the message header. Ten values or sets of values are encoded when the N message header is selected. One value or set of values is encoded when the P message header is selected.

2.4.8.2 Leading Modifier

The purpose of the leading modifier is specifiy whether a Time Block is encoded in front of a set of values. For example, it is standard practice to encode a time block in front of the primary water level sensor data. In order to accomplish this, the primary water level sensor format (normally the second, non-header line of the format file) will be preceeded by a T. An Aquatrak PWL sensor would have the format set to

TAQUATRAK

A BEI absolute encoder would be formatted as:

TMSO

2.4.8.3 Trailing Modifier

The trailing modifier serves two purposes:

It allows the user to control the number of bytes encoded for the primary value in a format – typically the mean of an average

It allows control over the scaling factor for those formats that use scaling

The default encoding of the primary value is two bytes. If the user wants the primar value encoded as three bytes the trailing modifier is set to 3. For example, the standard encoding format for a BEI encoder is MSO, providing two-byte encoding of the mean water level. If, instead, the format is set to MSO3, then the mean is encoded as three bytes instead. The encoding of the standard deviation and offset are not affected.



The trailing modifier can also be used to change the scaling for the water level formats. The standard scaling is 0.25. By adding the string /1 to a scaled format the scale factor is changed to one instead. For example, the AQUATRAK format uses the 0.25 scaling by default. If instead, the user specifies AQUATRAK/1, then the values are scaled by 1.0 instead.

2.4.9 AUX1 – AUX4

The AUX1 through AUX4 fields are only required with the following FORMAT settings:

AQUATRAK

MSO

WSWDG

The AUXn field identifies the XPert label associated with additional sensors to be encoded. For example, the AQUATRAK format requires entries in all four AUX fields. AUX1 identifies the label for the standard deviation. AUX2 identifies the label for the outlier count. AUX3 and AUX4 identify the labels for the Aquatrak tube temperatures.

Further information on how to set up the individual formats is provided in the next section. See also the example table at the beginning of Section 3.2.

2.5 USING THE BLOCK FORMATS

The block formats specify how you want information from one line of the table encoded into the GOES message. Each table line has one FORMAT field. The FORMAT field works with the Log Label and AUXn fields to assemble information within the message. The following paragraphs describe how the different formats assemble information.

2.5.1 WATER LEVEL FORMATS

There are three water level formats. All three water level formats have a common feature. This feature is the way in which water levels are encoded. In all three cases, the water levels to be encoded are scanned for the minimum value. This minimum value is subtracted from every water level. An offset is computed from the minimum water level and encoded as one byte. All the water levels are encoded into the message by first subtracting the offset and then encoding the result. The three formats differ only in the information that is included along with the water levels.

As with all good rules, there is an exception. If you use the trailing modifier of 3, the SCALING INFORMATION IS ELIMINATED. Why? Because the 3-byte encoding includes sufficient resolution to eliminate the need for scaling. The 3 trailing modifier is normally only used for six-minute transmissions (P header).



2.5.1.1 AQUATRAK (Scaled 5 parameters)

The AQUATRAK format is designed specifically for information from the acoustic Aquatrak sensor. The information encoded includes the offset, water levels, standard deviation of the water level measurements, the count of “outliers” (presumably bad values), and two Aqauatrak sound tube temperatures. When using the N header the information is encoded as illustrated in the following table.

Flag Offset Grp1 Grp2 Grp3 Grp4 Grp5 Grp6 Grp7 Grp8 Grp9 Grp10

The encoding of the offset will be done using 0.25 by default. If a scale factor of 1.0 is desired then a trailing modifier of /1 should be added to the format.

When using the P header the information is encoded as illustrated in the following table.

Flag Grp1

The Flag is assigned by the table row in which the AQUATRAK format is specified. Normally the flag will be an ASCII one ( 1 ), but can be set to other values.

Offset is a one-byte value computed from the minimum water level from the group of water levels being encoded. Scaling of 0.25 is the default, as discussed earlier.

Grp1 through Grp 10 are sets of information from one time. Each Grp contains:

Offset water level (2 bytes default, 3 bytes of AQUATRAK3 is specified)

Standard deviation (Sigma) (2 bytes)

Outlier count (1 byte)

Tube temperature 1 (2 bytes)

Tube temperature 2 (2 bytes)

The following is a table line for an AQUATRAK format. Note the use of the AUX fields to identify the sigma, outlier, and temperature sensors.

Description DPAS Code

Flag log label

#ST #RR Format Aux1 Aux2 Aux3 Aux4

Aquatrak A 1 PWL 10 3 AQUATRAK PWLSIG PWLOUT AQT1 AQT2



2.5.1.2 MSO (Scaled 3 Parameters)

The MSO format is exactly the same as the AQUATRAK format but the Grps contain only:

Offset water level (2 bytes or 3bytes, depending on trailing modifier)

Standard deviation (Sigma) (2 bytes)

Outlier count (1 byte)

The following is a table line for an MSO format. Note the use of the AUX fields to identify the sigma, and outlier sensors.

Description DPAS Flag log #ST #RR Format Aux1 Aux2 Aux3 Aux4

Backup WL B " BWL 10 3 MSO BWLSIG BWLOUT

2.5.1.3 M (Scaled 1 Parameter)

The M format is exactly the same as the AQUATRAK format but the Grps contain only:

Offset water level (2 bytes or 3 bytes, depending on the trailing modifier)

The following is a table line for an M format. Note the AUX fields are not used.


Backup WL B " BWL 10 3 M

2.5.2 GENERAL PURPOSE FORMATS (ANCILLARY ITEMS)

The general purpose formats are designed to insert single or groups of 10 values into a GOES message. The formats are designed around the requirements for ancillary sensors such as wind speed/direction, water temperature, and salinity.

2.5.2.1 SV (Unscaled Single Value)

The SV format is designed for encoding values that do not go negative. The information is encoded as indicated in the following table

Flag #1 #2 #3 #4 #5 #6 #7 #8 #9 #10

for the N header, or

Flag #1



for the P header.

The Flag is assigned by the table row in which the SV format is specified. Normally the flag will be set according to the type of information being encoded (See Section 3.2), but the flag can be set according to the user’s needs and the requirements of the GOES decoder being used.

#1 through #10 are encoded values (2 bytes each or 3 bytes, depending on the trailing modifier). The encoding is in the GOES standard 6-bit Pseudo-Binary format with no consideration for a negative value.

The following is a table line for an SV format. Note the AUX fields are not used.

Description DPAS Code

Flag log label

#ST #RR Format Aux1 Aux2 Aux3 Aux4

Aux Bat x 4 AXBAT 10 3 SV

2.5.2.2 SVS (Unscaled, Signed Single Value)

The SVS format is designed for encoding values that may go negative. The information is encoded as indicated in the following table

Flag #1 #2 #3 #4 #5 #6 #7 #8 #9 #10


Flag #1

for the P header.

The Flag is assigned by the table row in which the SVS format is specified. Normally the flag will be set according to the type of information being encoded (See Section 3.2), but the flag can be set according to the user’s needs and the requirements of the GOES decoder being used.

#1 through #10 are encoded values (2 bytes each, or 3 bytes, depending on the trailing modifier). The encoding is done as Two’s Complement 6-bit Pseudo Binary so that negative values have a sign bit.

The following is a table line for an SVS format. Note the AUX fields are not used.


Air temp

D 4 AT 10 3 SVS



erature



2.5.2.3 WSWDG (Wind Speed, Direction, Gust)

The WSWDG format is designed specifically for information from wind sensors. The information encoded includes the speed, direction, and gust measurements. The information is encoded as illustrated in the following table.

Flag Offset Grp1 Grp2 Grp3 Grp4 Grp5 Grp6 Grp7 Grp8 Grp9 Grp10

When using the P header the information is encoded as illustrated in the following table.

Flag Grp1

The Flag is assigned by the table row in which the WSWDG format is specified. Normally the flag will be an ASCII one ( 3 ), but can be set to other values.

Grp1 through Grp 10 are sets of information from one time. Each Grp contains:

Wind speed (2 bytes) Wind direction (2 bytes) Period Gust (2 bytes)

Unsigned encoding in 6-bit Pseudo-Binary is used for all three items.

The following is a table line for a WSWDG format. Note the use of the AUX fields to identify the direction and gust data.


Windbird C 3 WS 10 3 WSWDG WD WG



2.5.2.4 BAROM (Offset Barometric Pressure)

The BAROM format is designed for encoding values from a barometric pressure sensor. The format is identical to the SV format except that 800 is subtracted from each value before encoding. This is done to make better use of the 12 bits available for representing a number (enhanced resolution).

Flag #1 #2 #3 #4 #5 #6 #7 #8 #9 #10


Flag #1

for the P header.

The Flag is assigned by the table row in which the BAROM format is specified. Normally the flag will be set according to the type of information being encoded (See Section 3.2), but the flag can be set according to the user’s needs and the requirements of the GOES decoder being used.

#1 through #10 are encoded values (2 bytes each or 3 bytes, depending on the trailing modifier). The encoding is in the GOES standard 6-bit Pseudo-Binary format with no consideration for a negative value. The value 800 (presumes that pressure is in mill bars) is subtracted from each number prior to encoding.

he following is a table line for a BAROM format. Note that the AUX fields are not used.


Barometer F 6 BP 10 3 BAROM



3 NOS GOES STORM SURGE (RANDOM REPORTING) FORMAT

3.1 PARAMETER CODE MAPPING

The format table has limited influence on the Storm Surge format. The table is used to map the XPert setup (in this case the parameter labels) to the NOS flags for the water level sensor, wind speed and direction sensors, and the barometric pressure sensor.

3.2 THE FORMAT

A complete Storm Surge message is 26 total bytes, as shown in the following table:

MESSAGE: S HR MIN OFF WL WL WL WL WL WL 3 WS WD WG 6 BP

BYTES: 1 1 1 1 2 2 2 2 2 2 1 2 2 2 1 2

CHARACTER

START POSITION

1 2 3 4 5 7 9 11 13 15 17 18 20 22 24 25

ZERO-BASE INDEX 0 1 2 3 4 6 8 10 12 14 16 17 19 21 23 24

Where:

Mandatory Values

S ASCII “S” -- message header

Hr, Min Hour and Minute of most recent water level value

Wl Six water level values

Optional Values if defined in setup

3 ASCII “3” -- GOES Wind flag

Ws Wind Speed

Wd Wind Direction

Wg Wind Gust

6 ASCII “6” -- GOES Barometric pressure flag

Wind speed, direction, and gust values are based on the most recent six minutes if the setup defines 10 values per hour or on the most recent hour if the setup is using hourly averaging.



4 DIAL-IN REPORTS

4.1 DIAL-IN REPORTS CONCEPT

A specially-developed XPert DLL called NOS Report provides the ability to dial in to a modem-equipped XPert and obtain information. Two types of reports are provided. The first is called the NOS Ports Tag Report. It is based on a report of the same name that was available in Sutron 9000-based Tide Stations. The second is called the Table-Controlled Report. This is a new report that takes advantage of the information in the GOES format control table.

The following paragraphs explain the concepts of the reports and how to obtain and use them.

4.2 SETTING UP FOR DIAL-IN REPORTS

The XPert must be properly configured in order to obtain the dial-in reports. The requirements are:

NOS Report DLL must be present

XPert must be equipped with a modem that allows a dial-in connection

One or more Usernames and Passwords must be defined on the XPert

The Username(s) must be assigned to appropriate User Groups

XPerts equipped with the NOS Report DLL provide two user groups. These two groups are:

1. NOSReport

2. NOSCustRpt

Users assigned to the first group will receive the NOS Ports Tag Report when they dial in and give the correct Username and Password. Users assigned to the second group will receive the Table-Controlled Report.

You must have SETUP access to the XPert to define Usernames and Passwords. Go to the SETUP tab and expand the Users branch of the tree. There you can ADD new Users or edit existing Users. The User Group is a property of each user and is assigned in the same window as the Password.



4.3 NOS PORTS TAG REPORT

4.3.1 THE FORMAT

The NOS Ports Tag report is designed to present all of the potential information from a Tide Station to a dial-in user in a specified format. If a sensor is present then values are given. If a sensor is not present or the data are corrupted then a series of nines are presented instead. The general appearance of the Ports Tag report is as follows:

PORTS TAG REPORT

NOS NGWLMS Xpert 03/01/2002 08:48:00 0.000,0.000 0,99999,99999999999,99999,99,99999,99999999,999,999999999999999999999999999999,999999999999999999999999999999999,99999,99999999,99999,9999990999999999999999999999999999999-0.10100000000000000DATA COMPLETE

4.3.2 PARAMETER CODE MAPPING

Each line of the Ports Tag reports contains one or more specific sensor values (e.g. primary water level). The format table is used to determine which of the XPerts parameters is the required sensor. The mapping is done by scanning the table for a specific “Flag”. The “Log Label” field of the table identifies the XPert sensor for the “Flag”. (See section 3.2, which follows.)



4.4 TABLE-CONTROLLED REPORT

4.4.1 THE FORMAT

The general appearance of theTable-Controlled Report is as follows:

Table-Controlled Report

NOS NGWLMS Xpert 08/19/2003 13:34:30A 1 1024.000 2.500 2.500 2.500 2.500C 3 Data flagged as bad or missingB " Data flagged as bad or missingDAT 99999.999SNS 99999.999BWLG data not availableBWLO data not available

REPORT COMPLETE

4.4.2 SETTING UP A REPORT

The first step in setting up a report is to define one or more Users and assign them to the NOSCustRpt group. Only users assigned to the NOSCustRpt group will see the Table-Controlled Report when they dial in. Note that users will only see one type of report. It is not possible at this time to select the report based on the Password or other paramater.

The report header is fixed. That is, there is nouser control of its format or content.

The body of the report is set by the field settings in the GOES Format Control Table.

The Sequence Number field determines whether information for a particular parameter will be included in the report. If the Sequence Number is set to zero (0), then no information for the parameter(s) in the table line are included. A Sequence Number between one (1) and thirty (30) determines the order in which information is presented. The Sequence Numbers do NOT have to be sequential. Control is based on relative magnitude and not numerical order. The sequences 1,2,3 and 6,9,24 will both output lines in the same order.

NOTE: Do not enter adjacent commas in place of a zero for the sequence number.

The contents of the LOG LABEL and AUXn fields determines the content of each line of the report. The report generator gets the last logged value for each of the parameters identified in these fields and places them in a report line. Each line begins with the NOS DPAS code and GOES flag for the LOG LABELed item so that the information on a line in uniquely identified.



5 ASSEMBLING A GOES MESSAGE

5.1 NOS GOES SELF-TIMED FORMAT

The NOS GOES self-timed message format is composed of a header followed by a number of blocks. Each of the blocks beyond the header is identified by a flag that allows a decoder program to identify the content of the block.

The overall structure of an “N header” NOS GOES self-timed message is as follows:

Header WL block Block Block More Blocks ---- Redundant WLs Trailer

The overall structure of a “P header” NOS GOES self-timed message is as follows:

Header WL block Redundant Water level

Block More Blocks ---- Trailer

5.1.1 THE STANDARD N HEADER

The standard N message header is fixed in format and contains the following information:

ASCII “N” indicating NOS “new” message formatStation ID 8 bytes identifying the DCP sending the message. ID starts a left side of

field.Datum 3 bytesSensor offset 2 bytesUnused 5 bytes - system status (2 bytes), #resets (1 byte) and checksum (2 bytes)

These are old Sutron 9000 concepts and are hard coded to zero (@@@@@).

Time offset Binary encoded minute of the hour of the most recent water level Time block Flag (1 byte - ASCII 0), Sutron Day (2 bytes), hour (1 byte)

Sutron day, counted as the number of days since 12/31/84 modulus, the maximum number of values representable by a 2 byte 6bit binary number (4096). IMPORTANT: Refer to section 5.2 on inserting this time block!

5.1.2 THE 6-MINUTE P HEADER

The 6-minute P message header is fixed in format and contains the following information:

ASCII “P” indicating NOS 6-minute message formatStation ID 8 bytes identifying the DCP sending the message. ID starts a left side of

field.Datum 3 bytesSensor offset 2 bytesSysStat 2 bytes - system status (2 bytes)



Time offset Binary encoded minute of the hour of the most recent water level (1 byte)Time block Flag (1 byte - ASCII 0), Sutron Day (2 bytes), hour (1 byte)

Sutron day, counted as the number of days since 12/31/84 modulus the maximum number of values representable by a 2 byte 6bit binary number (4096) IMPORTANT: Refer to section 5.2 on inserting this time block!

5.1.3 REMAINDER OF MESSAGE

The remainder of the message is composed of blocks of data. Each block begins with a flag that identifies the type of data in the block.

The message ends with Redundant water levels (if space is available) and a message trailer that contains:

ASCII “ “ space characterBattery (1 byte) (voltage - 9.5) * 10 BWL gain ( 2 bytes) Backup water level gain (Must be labeled BWLG in XPert

setup)BWL offset (3 bytes) Backup water level offset (Must be labeled BWLO in XPert

setup)

The standard GOES message includes an EOT character at the end. This character is appended by Satlink/XPert.

FLAGS AND CODES

Description GOES flag DPAS codeTime tag 0

Aquatrak water level 1 A

Redundant water level (by whatever means measured) >

Backup water level (by whatever means measured) “ B

Wind data (speed, direction, gust) 3 C

Air temperature 4 D

Water temperature 5 E

Barometric pressure 6 F

Frequency #1 +

Shaft angle encoder !

Redundant shaft angle encoder . (dot)

Conductivity 7 G

Unasigned 8

Relative Humidity 9

Rainfall : (colon)

Solar Radiation ; (semicolon)

Analog 1 <

Analog 2 =

Description GOES flag DPAS code



Paros Scientific transducer #1 % N

Paro Scientific transducer #2 & P

Redundant Paros #1 ‘ (single quote)

Redundant Paros #2 * (asterisk)

Encoding of the data beyond the flag depends on the type of data. The encoding is explained in the description of the block formats in the paragraphs that follow.

Most messages are composed of the header, water level data (primary sensor), backup water level data, ancillary data (e.g. wind speed, direction, gusts), and redundant water level data if space is available.

5.1.4 WHAT YOU CAN CONTROL

5.1.4.1 Mapping of Parameter Codes

The XPert allows treat flexibility in the naming of items saved in its log and the naming of values in the GOES transmission buffers. The table allows you to identify any piece of data beyond the message header by any name you wish. (How this is done is explained later.)

5.1.4.2 Block Formats

The table completely defines the message content beyond the header. You can select what parameters are transmitted, the order in which they are transmitted, the flag that identifies each parameter, and the encoding of the values. (Again, how this is done is explained later.)

5.1.4.3 Number of Values

You have SOME control over the number of values encoded beyond each flag. Control is at two levels:

1. Header type (P or N)

2. XPert setup

The primary control of the number of values is set by the XPert settings. There are only two options. If you have set the XPert up to collect 10 values per hour, you can transmit one, or 10 values. If you have set the XPert up to collect only a single value per hour than that is the only option for number of values in the message blocks.

Selecting the 6-minute P header overrides ALL other XPert settings and will force single-value or value set encoding for all message parameters.



5.1.5 WHAT YOU CAN’T CONTROL

5.1.5.1 Hard-Coded Parameters

The self-timed GOES message format header and trailer contain values that MUST BE IDENTIFIED by hard-coded labels. The hard-coded labels are:

DAT The station datum

SNS The water level sensor offset

BAT The system battery voltage

5.1.5.2 Redundant Water Levels

Redundant water level data is information from previous time steps that has been incorporated in previous transmissions. The amount of redundant water level information is determined by the message header (N or P) and the number of water level sensors specified in the table. The handling of redundant data for the N and P formats is completely different. The differences are described in the following paragraphs.

Redundant data for N header messages is added after the XPert has assembled a message according to the contents of the table and the XPert setup. The formatter determines if there is room for redundant water level data. If room is available, up to three additional hours of primary water level data (the sensor identified in the first line of the table) will be encoded and added to the message before the message trailer. If more than one water level sensor is present then redundant data for that sensor is also included.

Redundant data for P header messages is added immediately after the current data (the value for the current six-minute period A single redundant value (mean only) is added for each water level sensor. For example, if there is a single water level sensor, then a six-minute transmission will contain the current water level (average for last six minute period) and the average for the previous six minute period. If there are two water level sensors (e.g. WL1 and WL2), then the message will contain WL1 current data, WL1 previous six minutes, WL2 current data, WL2 previous six minutes. Redundant data for the six minute messages is always encoded in three bytes, regardless of the formatting specified for the current data.



5.2 TABLE ROWS TO MESSAGE BLOCKS

The central portion of the NOS GOES self-timed message between the header and the redundant water level block is entirely controlled by the table. There is a one-to-one correspondence between the table rows and the central blocks.

Message:Header WL block Backup WL block Wind data

blockRedundant WLs Trailer

TableSequence

#Description DPAS

CodeFlag Log

label#ST #RR Format Aux1 Aux2 Aux3 Aux4

1 Aquatrak A 1 PWL 10 3 TAQUATRAK PWLSIG PWLOUT AQT1 AQT2

3 Backup WL B " BWL 10 3 MSO BWLSIG BWLOUT

2 Windbird C 3 WS 10 3 WSWDG WD WG

It is implicitly assumed that the FIRST Non-header row is the PRIMARY WATER LEVEL sensor. This is the ONLY assumption made. Every other row can be any sensor and the rows are not required to be in any particular order unless the order is important to the GOES decoder at the central receive site.

You MUST specify the T modifier for the format of the PWL sensor. Failure to include the T will result in a message without the mandatory time block in front of the first value. This time block is part of the header (both N and P headers), but it is inserted in the message as part of the processing associated with the first table line.

The order of the blocks in the message will correspond to the order in the table. That is, the PWL will be encoded first according to the format specified. After that, the rows are taken one at a time and a block is created according to the settings in the row.

NOTE: The flags specified in a table row ARE NOT automatically checked to ensure that they adhere to NOS standards. That is, it is perfectly acceptable to the software to set the PWL flag to ?. If the flags are



important to you then it is your responsibility to see that they are correct. If the flags do not meet NOS standards, they will cause the NOS Ports Tag report to contain incorrect or missing information.



5.3 REDUNDANT WATER LEVELS

Redundant water level (RWL) data are only added if space is available in the hourly transmission messages (N header). Refer to the discussion in section 5.1.5.2. Redundant data values are always inserted in 6-minute messages. Again refer to the discussion in 5.1.5.2.

NOTE: The XPert GOES setup must account for the redundant water levels in the hourly (N header) transmissions. Data for the GOES messages does NOT come from the Log. It comes from buffers within the Satlink software. The number of values count for the water level (and any sensor reported along with it, such as the sigma and outliers) must be set high enough to allow redundant transmissions. For typical NOS applications (N header), the value should be set to 42. This allows for one primary hour and three redundant hours at 6-minute collection intervals. The P header messages automatically include one redundant value for each water level sensor.

5.4 MESSAGE TRAILER

The message trailer contains:

ASCII “ “ (1 byte) space character

Battery (1 byte) (voltage - 9.5) * 10

BWL gain ( 2 bytes) Backup water level gain (Must be labeled BWLG in XPert setup)

BWL offset (3 bytes) Backup water level offset (Must be labeled BWLO in XPert setup)

The standard GOES message includes an EOT character at the end. This character is appended by Satlink/XPert.

5.5 MESSAGE LENGTH CONSIDERATIONS

The NOS GOES formatter DOES NOT check for adequate message space within a transmit window. It is the USER’S RESPONSIBILITY to make sure the encoded message will fit within the allowable time. Space is critical in the 6-minute P-header messages. The actual time available for information is around 3 seconds. This is sufficient time for only around 100 characters.



6 TROUBLESHOOTING

6.1 WHAT CAN GO WRONG?

The following table indicates some of the common problems that can occur when using the NOS GOES format control table.Problem Possible Solution

Error message indicating that the setup does not define a GOES message

The XPert is missing hard-coded parameters required for the message header. Check to make sure that the DAT and SNS sensors are defined in the setup. BAT should also be defined. These parameters MUST be connected to Self-timed parameter blocks (Antenna Icon) and the labels MUST be correct.

Data values are missing from the NOS Ports Tag report even though the data are being collected

The NOS Ports Tag report contains several items that require hard-coded parameter labels. Make sure that your XPert setup contains the correct labels.

Block of data is missing

Export the table from the XPert and make sure that the last line is not corrupted. Occasionally the last line of a table will loose the end-of-line character and cause the information in the line to be ignored or misinterpreted.

Check the spelling of the Format. Make sure the format is entered in capital letters.

One or more items are missing from the water level block or a wind data block

Make sure the AUXn fields are entered correctly. The AUX fields must correspond to labels set in the XPert.

One or more items in the water level block or a wind block are out of order.

Make sure the AUXn fields are entered correctly. The AUX fields must correspond to labels set in the XPert.

Decoder puts information in the wrong place

Flags in table rows must be set so that the decoder understands the type of information in a block. For example, an Aquatrak sensor must be encoded with flag = 1 if that is how the decoder identifies an Aquatrak

Not enough data values for a complete block (several time periods encoded as ??

The appearance of the ?? set is normal for several hours after recording starts because it takes time for the Self-timed buffers to fill with the specified number of values. If the number of values in the self-timed setup is set too low (for example 5 instead of 10 or 11 when collecting data every 6 minutes for an hour) Then you will always see ??s because there will not be enough data to complete the block each hour.

Setup and table appear OK but all values encoded as ??

Check the right digits setting in the XPert setup. Too many right digits may cause the resulting numbers to overflow the 6/12 bit Pseudo-Binary encoding.

GOES message is OK, but the table-controlled report contains no data

The labels in the Selft-timed message block do not match the labels in the log. The report gets data from the log and thus for both the GOES message and the report to work at the same time, the labels must match.

No data in table-controlled report Make sure that at least one line of the table has a non-zero sequence number.



6.2 ERROR AND STATUS MESSAGES

The following table lists the specific error messages that may be reported in the XPert Status window. The likely cause and solution are also presented.

Message in Status Panel Likely Cause/Solution

SelfTimedMsgr::NOSGetFmtIndex Invalid block format xxxx in line n

There are only seven valid formats. They must be entered in capital letters and spelled correctly. Line “n” identifies where in the table to look for the error.

SelfTimedMsgr::FormatNOS Format table missing or empty

The format control table has not been copied to the XPert \Flash Disk, or was accidentally deleted.

An empty table is a table with only the header row.

SelfTimedMsgr::FormatNOS Error formatting AQUATRAK

SelfTimedMsgr::FormatNOS Error formatting MSO

SelfTimedMsgr::FormatNOS Error formatting M

SelfTimedMsgr::FormatNOS Error formatting SV

SelfTimedMsgr::FormatNOS Error formatting SVS

SelfTimedMsgr::FormatNOS Error formatting WSWDG

SelfTimedMsgr::FormatNOS Error formatting BAROM

These errors occur when the XPert cannot find data for the specified format. The most likely cause is that the Log Label and/or one or more of the AUX fields is entered incorrectly. These labels MUST match the exact spelling in the XPert setup for the Self-timed parameter blocks (which don’t necessarily match the labels in the Log).


sutron standard format - division of nearshore...

Documents