1.1 Introduction

The Environmental message is intended for a wide variety of environmental data, including: current flow, water level, water temperature, visibility, and air gap. The message has the ability to provide both real-time and forecast data. A message version number is includes in the SR0 parameter to indicate which version of the message is being used.
In order to maximize flexibility, this message can be used to transmit from 1 to 8 sensor reports (a 1 sensor report uses 1 slot while a message with 8 sensor reports requires 5 slots). These sensor reports can be data from one location or from multiple locations. In addition, the data does not need to be sent at the same update rate allowing data that changes more rapidly to be sent more often than slowly changing data. Static data such as sensor position can be sent even less frequently.
The framework for the Environmental message is shown in Table 1. Each Environmental message has 56 bits of standard header and from 1 to 8 sensor reports (112 bits each). Each sensor report has 27 bits of common data leaving 85 bits for sensor data. The framework for the sensor report is shown in Table 3. There are a variety of sensor types that can be transmitted using this message; 4 bits gives 16 possible values, these are listed in Table 4. Details for the 85 bits of information for each sensor report type are detailed in Tables 5 – 15. All possibilities for each data parameter are described. In each case Sensor Not available means that the specific reading is not ever possible from that sensor location. Data Not available means that the reading is possible, but is not available for the current report (sensor could be malfunctioning).

All directions are relative to True North, all positions are WGS-84 Datum.

1.2 The framework for the Environmental message is shown in Message Format (details)

Table 1. Each Environmental message has 56 bits of standard header and from 1 to 8 sensor reports (112 bits each). Each sensor report has 27 bits of common data leaving 85 bits for sensor data. The framework for the sensor report is shown in Table 3

Table 3. There are a variety of sensor types that can be transmitted using this message; 4 bits gives 16 possible values, these are listed in Table 4. Details for the 85 bits of information for each sensor report type are detailed in Tables 5 – 15. All possibilities for each data field are described. In each case Sensor Not available means that the specific reading is not ever possible from that sensor location. Data Not available means that the reading is possible, but is not available for the current report (sensor could be malfunctioning). All directions are relative to True North, all positions are WGS-84 Datum.

1.3 Usage notes

1. The Site ID is used to link the site location, identification, and sensor data. A single location may have multiple physical sensors at that location, generating a variety of data elements, allowing for the creation of multiple sensor reports from that location.
2. From 1 to 8 sensor reports can be assembled into a message; these can be from the same site or multiple sites. The number of reports assembled into a message is an operational decision based upon the maximum number of slots that are desired to be used for a single message. A single slot message can be created by using just one sensor report while it takes 5 slots to send a message with 8 sensor reports.
3. Up to 5-slot messages can be created, but messages with more than 3 slots should be avoided as messages with more slots are less likely to be received due to RF noise or packet collision.
4. The transmission schedule of the message should be based upon the latency of the data and the maximum time that a new user should expect to wait to receive the data. For example, NOAA PORTS^® data is updated every 6 minutes, so it would be prudent to broadcast it every 3 minutes, thus ensuring at least two opportunities to receive the data in the sensor’s epoch. In cases where data is updated infrequently (such as daily or hourly) the transmission schedule should be on the order of every 5 to 10 minutes to ensure that a new user does not have to wait overly long to receiver the message.
5. The sensor reports are a combination of dynamic and static information; the static information such as location and identification should be transmitted less often than the dynamic information (sensor readings).
6. The competent authority should always transmit the most recent data (based upon the timestamp of the data) available; older versions of the same data elements should not be transmitted. Data should also not be transmitted past the data expiration time.
7. Portrayal systems should automatically update upon receiving new data. Users should be able to retrieve the time of the data and the last data received.
8. Presentation software should automatically remove the data from the display once it is past the expiration date/time.
9. Since a Sensor Report 0 (Site Location) must be received before the relevant sensor data can be used, the EM version number is part of this report. If the received version number is different than what the display system has been programmed for, a message should be displayed to the operator indicating the mismatch in the version.
10. The Site ID can also be used to link additional text (e.g., a separate text message). However, the same source MMSI needs to send both the Environmental Message and additional Linked Text message (See Linked Text Message).
11.  Some of the sensor reports include provisions for short-term forecasts or NowCasts. These are intended to be limited to only a few hours in the future and are only valid for a maximum of 255 minutes from the start of the forecast. The UTC day is included as part of the start time of the forecast to allow for the cases when it is near the end of the current day and a forecast a few hours in the future would fall on the next UTC day.