by James W. Hebert
This article attempts to explain the content and structure of digital selective calling messages, not as transmitted by the radio over the airwaves, but as sent to other ship electronic devices over the wired data link from a radio that has received and processed a DSC call. I present my own observations of this data, and my own deductions. As far as I can tell, my observations are accurate, that is, I have captured the data being sent as it was actually sent from the radios used in these experiments on their wired data links, however, I do not know for certain if my deductions about the content and structure of the data are similarly correct. I have made a number of inferences and deductions about the content and structure of the data I observed, and tried to fit those into an understanding of the method being used.
This article is the third article in a series of four article I have written in which the behavior of DSC radios is tested and examined. The index below provides access to all four articles:
When two digital selective calling radios communicate, the details of the method they will use are given in the open standard ITU-Rec. M.493-13. That reference describes in very great detail how the messages will be encoded and formated, how the transmitter will be modulated, and upon reception, how the signals are to be interpreted. It also provides for a data link to the radio, which should be implemented in accordance with another international standard, IEC-61162. The information that is sent by a Class-D DSC radio on its data link when it has received a DSC message is the main interest of this inquiry. But the ITU-Rec. M.493-13 standard does not specify exactly how information received by a DSC device is to be passed along to other ship electronic devices via its wired data link. It seems reasonable to assume that the datagrams sent on the data link will contain some of the same elements as used in the radio transmission of the message, but not all elements from the radio method will necessarily be used. For example, the radio message must clearly contain some sort of addressing mechanism. This address data may not be sent from the DSC device on its wired data link. If the DSC device has received the message and processed it, one can assume the message was addressed to that device.
When signals are sent over directly wired data links instead of over radio, the encoding of the signals can be simpler. For example, for radio transmission there is a detailed description of how the actual data content of a message is wrapped between other elements that are provided to help the receiver synchronize its demodulator with the sender's transmission. Because of a possibility of mutilation of a radio signal at the receiver, data sent via radio is often encoded with error checking or error detection methods.
In ITU-Rec. M.493-13, we learn that seven-bit data is sent as a ten-bit representation or symbol:
1.5 The information in the call is presented as a sequence of seven-bit combinations constituting a primary code.
1.5.1 The seven information bits of the primary code express a symbol number from 00 to 127, as shown in Table 1, and where:
1.5.1.1 the symbols from 00 to 99 are used to code two decimal figures according to Table 2;
1.5.1.2 the symbols from 100 to 127 are used to code service commands (see Table 3).
This suggests that all transmitted data is wrapped with its own error-checking code embedded into the signal. These are called "symbols" and are differentiated into two types, 00 to 99 to code two decimal figures and 100 to 127 to code service commands. You can think of the first group as the data, and the second group as data about the data, or metadata. Both are seven-bits of information wrapped in a ten-bit code to give error checking, and these representations are called symbols. When data is sent over a wired connection, a simpler method can be used, and the data may no longer be encoded in symbols, but sent as the original data, or in some cases, sent as even simplified version of the original data if a reasonable basis exists to differentiate between the data and metadata. Such a basis might be simply the position of the coded data in the datagram.
The ITU-Rec. M.493-13 explains how to compose and send various types of messages. This information begins in Section 2, under the heading "Technical format of a call sequence." A call sequence will consist of four elements:
Since we are not trying to build our own radio, but only want to understand the data link interface of an existing radio, we concentrate mainly on the call content and not on the other elements of a call sequence. In ITU-Rec. M.493-13, a great deal of detail and explanation is given to describing the call content segment. It is mainly explained in several tables in Section 4, although perhaps not as clearly as one might hope. Several tables describe how to encode data into symbols. Table 3 is used to encode data of the type code service commands, and is used for much of the following encoding. Other tables describe how to form calls of different types.
The call content of a distress alert message is described in various sections and in Table 4.1, and will consist of the following elements:
The call content is first described by a "format specifier" element. The format specifier is explained in Section 4, with various symbol codes in the "service command" range of symbols representing various message formats, as shown in Table 3 (by symbol number, then meaning of symbol) as follows:
The call content is next described by an "address" element in Section 5. The address is usually a representation of a ship's maritime mobile service identity (MMSI). The address is always sent as a ten-digit element, with a trailing zero appended to a nine-digit MMSI. Section 5 explains that calls to all ships or distress alert calls do not have an address, since they are implicitly a call addressed to all stations. (It is also possible to compose an "address" by specifying a geographic region. I don't think this type of address can be used on VHF, and not by Class-D radios, so no consideration will be given to it here.) Note that this address element, while necessary in the radio transmission to direct the call to the appropriate recipient, is not necessarily needed in the data link datagram; we already know the call must have been addressed to a particular radio in some manner, as the radio has gotten the call and processed it into its message contents. On this basis, we can expect to not see an address element in the data link datagram.
The call content is next described by a "category element" in Section 6. Again, various symbol codes in the "service command" range of symbols represent various categories, as follows from Table 3 (by symbol number, then meaning of symbol):
The call content is next described as having a "self-identification" element. This is simply the sending station's MMSI, encoded like the address element. This identifies who sent the message.
ITU-Rec.M.493-13 finally gets into describing the actual messages elements that can be contained in the call content of a DSC transmission in Section 8. The messages elements that can be sent depend on the format specifier of the call. We first examine the distress alert message format. A chart at Table 4.1 describes the call sequence format for distress alert calls made on VHF radios of Class D type.
For a call of message format type distress alert, the message elements are as follows, and are sent in the order shown below (as shown in Table 4.1):
Nature of Distress is to be encoded, again using Table 3, as follows
Distress coordinates are to be encoded five parts, sent as a string of ten digits. The first digit indicates the direction of the latitude and longitude, with "0" for North and East, "1" for North and West, "2" for South and East, and "3" for South and West. The next two digits are the latitude in degrees. The next two digits are the latitude in whole minutes. The next three digits are the longitude in degrees. The next two digits are longitude in whole minutes.
The time in universal coordinated time is to be sent in 24-hour format in two parts, a total of four digits. The first two digits are the hours. The next two are the minutes.
Since digital selective calling is often used to set up another call, this message element gives the preference for follow-on communication modes.
The four message elements are inserted into the call content, giving an overall call sequence for the distress alert message, which is shown in Table 4.1:
Again, this is the sequence for transmission on the radio. We should expect some of these same elements to appear in the datagram on the data link, but perhaps not all or them and perhaps not in the same order.
At this point, we will examine a sample of a message sent over the data link of a DSC radio when it has received a distress alert message to see if we can gain insight into the content of the message and its format on the data link.
Using two DSC Class-D radios on a test bench, I conducted a test. Using Radio-A, a DSC distress alert message was sent. The message was received by Radio-B, which interpreted its message, and presented information on its data display and on its link interface. The signal on the data link interface was captured by my data terminal. Upon receiving the call from Radio-A, Radio-B sent the following data on its data link:
$CDDSC,12,3380400790,12,06,00,1423108312,2019,,,S,E*6A
We now examine the thirteen elements of the message and seek to understand how to interpret them. For interpretation I am guided by my knowledge of:
The first step to is separate the message into component parts, which are clearly delineated by the comma separators. (Below I have added some blank spaces that were not in the message for clarity in my numbering method.)
1 2 3 4 5 6 7 8 9 10 11 12 13 | | | | | | | | | | | | | $CDDSC,12,3380400790,12,06,00,1423108312,2019, , , S, E *6A
Now I examine my sample datagram and interpret it as follows, with the numbers 1 to 13 indicating the separate elements or fields of the datagram as I have diagrammed it above:
There is a lot of evidence that the command code symbols listed in Table 3 for use with ITU-Rec. M.493-13 for transmission via radio between DSC radios are typically shortened to two-digits from three-digits for sending as part of a datagram on the data link output of a DSC radio to connected electronic devices on a ship according to IEC-61162. With that in mind, I recreate Table 3 as it might apply to the data link datagrams, that is, with the leading "1" removed from command codes 100 to 127. Also, I delete the references to phasing positions, first and second tele-commands, and very obscure format specifiers, all for clarity. (See the original to learn about the deleted elements.) I use "Call Type" instead of "Format specifier" for clarity. This table is perhaps easier to use as a reference to interpret the meaning of encoded data in the datagrams sent on the data link output of a DSC radio that uses IEC-61162 coding, as specified in ITU-Rec. M.493.13.
Encoding in DSC radio data link output | ||||
---|---|---|---|---|
CODE | UNIQUE FUNCTION | CALL TYPE | CATEGORY | NATURE OF DISTRESS |
00 | Routine | Fire, explosion | ||
01 | Flooding | |||
02 | Geographic | Collision | ||
03 | Grounding | |||
04 | Listing | |||
05 | Sinking | |||
06 | Adrift | |||
07 | Undesignated | |||
08 | Safety | Abandoning ship | ||
09 | Piracy | |||
10 | Urgency | Man overboard | ||
11 | ||||
12 | Distress | Distress | EPIRB Emission | |
13 | ||||
14 | Group | |||
15 | ||||
16 | ||||
17 | AckRQ | |||
18 | ||||
19 | ||||
20 | Individual | |||
21 | ||||
22 | AckBQ | |||
23 | ||||
24 | ||||
25 | ||||
26 | ||||
27 | EOS |
In the column "Unique Functions," there are three uniquely encoded signals listed: EOS, ACK RQ (EOS), and ACK BQ (EOS). (By unique, I mean these symbols are only used for one purpose in any message. Some other symbols are used for as many as three purposes in a message, depending on where in the message sequence they are transmitted.) EOS is apparently "end of sequence" without any acknowledgement being requested or sent. ACK RQ is apparently a variation on the end of sequence indicator and may be sent on calls when the sender wants to request an acknowledgement of the message by the recipient, thus perhaps "acknowledgment requested." ACK BQ is apparently another variation on end of sequence, sent by a station in its reply message to the original station, giving the requested acknowledgment, or "acknowledge back". (Inferred from Table 3 and from GMDSS literature explaining an earlier version of ITU-Rec. M.493, which seems to be omitted from the most recent version.)
In the datagrams seen on the wired data link from the radio, it appears that EOS (end of sequence, Symbol 127) is coded as "S", as seen in the example above. Similarly, in other datagrams I have observed, ACK BQ (acknowledged back, Symbol 122) appears to be coded as "B". Again, this is based on seeing these used in datagrams observed during testing. The command code ACK RQ (acknowledgment requested, Symbol 117) has not been seen in any output datagrams, but is anticipated to perhaps be coded as "R".
To summarize the content of the datagram being analyzed, it is a digital selective calling message:
In testing a very recently made Class-D DSC radio, I came across a new datagram associated with a distress alert message. This radio, a GX1700 from Standard-Horizon, provides the ability to send a distress alert cancel message if the original distress alert message was sent in error. When another DSC radio (a GX1500S) received the distress alert cancel message, it notified me via its display screen that it has received a distress alert cancel. It also output a datagram, which I assume was indicative of the distress alert being cancelled; that datagram looked like this:
$CDDSC,12,3381581370,12,06,00,1423108312,0236,3381581370,,S,*20
This datagram is very interesting because it is the first I have seen in my investigation of the DSC datagram that has data in some fields that previously were always blank. Using the knowledge gained about the DSC datagram, I analyze this one as follows, giving only a full explanation for the new fields:
1 2 3 4 5 6 7 8 9 10 11 12 13 | | | | | | | | | | | | | $CDDSC,12,3381581370,12,06,00,1423108312,0236,3381581370, , S, *20
To summarize the content of the datagram being analyzed, it is a digital selective calling message:
In testing so far, the only other DSC call that produced some output on the data link was a reply to a position request call. I now look more closely at the datagram from that DSC call.
1 2 3 4 5 6 7 8 9 10 11 12 13 | | | | | | | | | | | | | $CDDSC,20,3381581370,00,21,26,1423108312,1902, , , B, E *7B
Based on some other sources, primarily some open source code for a NMEA parser I found on a developer's web page, it appears that Field-5 and Field-6 of a DSC datagram perform a dual function. In a distress alert message they have one function, but in a non-distress-alert message they have a second function; they are known as "first telecommand" and "second telecommand." This corresponds nicely with column headings in Table 3 of ITU-Rec. M.493-13. It appears that again only the trailing two digits are used. This suggests another variation of Table 3 using only the two digit symbols:
Encoding in DSC radio data link output for non-distress calls | ||
---|---|---|
CODE | First Telecommand | Second Telecommand |
00 | F3E/G3E All mode | No reason given |
01 | F3E/G3E Duplex | Congestion... |
02 | Busy | |
03 | Polling | Queue indication |
04 | Unable to comply | Station barred |
05 | End of call | No operator available |
06 | Data | Operator temporarily unavailable |
07 | Equipment disabled | |
08 | Unable to use proposed channel | |
09 | J3E telephony | Unable to use proposed mode |
10 | Distress Acknowledgement | (Weird--see original) |
11 | Medical transports | |
12 | Distress Relay | Pay-phone/public call office |
13 | F1B/J2B TTY-FEC | Facsimile |
14 | ||
15 | F1B/J2B TTY-ARQ | |
16 | ||
17 | ||
18 | Test | |
19 | ||
20 | ||
21 | Ship position | |
22 | ||
23 | ||
24 | ||
25 | ||
26 | No information | No information |
27 |
The encodings in the First Telecommand column look interesting, but the ones in the Second Telecommand column look rather obscure and unlikely to be seen in any messages sent from a Class-D radio, except for "26" meaning "no information." They appear to be related to setting up some sort of further call or communication, probably related to shore stations and probably on HF rather than VHF.
Interpreting field 5 and 6 from my table for the sample output shown above gives: First Telecommand: 21--ship position, and Second Telecommand: 26--no information.
Field-9 and Field-10 have no data (or null), as they have been in all datagrams observed so far with the exception of the distress alert cancel message. Apparently these fields are not used in a routine message.
To summarize the content of the datagram being analyzed, it is a digital selective calling message:
As noted in several of the examples above, a datagram from the wired data link of a DSC Class-D radio can include a signal that it will be followed by an expansion message. Expansion messages are discussed in ITU-Rec. M.821-1 in some detail, and the fields of the expansion message are given. The expansion message can contain various types of data, which are described by a "expansion data specifier" in Table 1. Below is that table with the symbols converted to two digits from three by removing a leading "1":
Symbols for expansion data specifiers | |
---|---|
Symbol | Expansion data specifier |
00 | Enhanced position resolution |
01 | Source of datum of position |
02 | Current speed of the vessel |
03 | Current course of the vessel |
04 | Additional station identification |
05 | Enhanced geographic area |
06 | Number of persons on board |
An example of an expansion message was seen immediately following a distress alert message. The datagram from a DSC radio that received the expansion message was as follows:
1 2 3 4 5 6 7 8 | | | | | | | | $CDDSE,1, 1, A, 3380400790,00,45894494*1B
Based on the above analysis, I can infer a general format for the NMEA message DSC as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 | | | | | | | | | | | | | $CDDSC,aa,bbbbbbbbb0,cc,dd,ee,fgghhiiijj,kkkk, , , m, n *xx
There is a limit to the forms for a DSC datagram that I can observe coming from a Class-D radio associated with a distress alert message if my testing limits me to sending calls from another Class-D radio. The specifications for Class-D radios only require a limited subset of features.
The Class-D radio can only send a few types of calls. These fall into two categories: distress calls and non-distress calls.
In terms of distress calls, the Class-D radio is limited to sending just two types: a distress alert message, and a special form of distress acknowledgment message that is interpreted as a self-cancel message. (This is mentioned in a footnote to a footnote in Table 4.2) There are other types of distress calls, such as a distress acknowledgement, distress relay, and distress relay acknowledgement, but these calls cannot be sent from a Class-D DSC radio.
The Class-D radio can also send non-distress calls. The required behavior for Class-D radio only specifies two types of non-distress calls:
Although not actually required to meet Class-D specifications in ITU recommendations, many radio manufacturers include several additional non-distress call functions in the radios they sell under the branding of "Class-D" DSC. These are:
The inclusion of these position polling features is now so common among Class-D DSC radios that most recreational boaters now incorrectly associate these features as part of the Class-D specificiation and thus expect them to be provided in a Class-D radio. The radios sold in the USA are only required by federal regulations to comply with the ITU recommendation ITU REC.M-493-13; that revision does not recommend position polling features for Class-D. In ITU REC.M-493-15, the current revision, position polling features are recommended for Class-D. A separate article explains how position polling calls have varied in the last three ITU recommendations.
The Class-D DSC radio can receive more types of calls than it can send. For distress calls, besides receiving a distress alert, a Class-D should be able to receive: distress acknowledgement, distress relay, distress relay acknowledgement. If I had another radio to test with that was a Class-A DSC radio, I could send these other types of calls and observe the output from a Class-D radio on its data link. This would help to understand more about the format of the data link datagrams. Unfortunately, I don't have a Class-A radio to experiment with. So far, I have only seen two types of distress calls produce output on the wired data link: a distress alert call, and a distress alert cancel call.
For non-distress calls, a Class-D radio appears to be able to receive the same types of calls it can send:
In addition, although not mandatory in ITU REC.M-49-13 3 recommendations for Class-D radios or earlier revisions, most Class-D radios can also receive:
The lastest revision ITU REC.M-493-15 now recommends Class-D provide position polling.
So far I have only seen one type of non-distress call produce output on the wired data link: a position request acknowledge back call returned in response to a position request call.
At this point, I believe I have seen the three forms of data link output that can occur from a Class-D radio if tested only with another Class-D radio:
I will have to look for other methods of testing to generate other types of calls, and to see if any output occurs on the wired data link.
In the process of studying the digital selective call radio system and the distress alert message that it can transmit and receive, I have noted that the message or signal travels a complicated path from a human sender to a human recipient, with various machines handling the message in the process. In the signal flow there are various interfaces, and at these interfaces various standards seem to apply. A simple analysis looks like this:
For ships, perhaps IEC-61174, "Maritime navigation and radiocommunication equipment and systems–Electronic chart display and information system (ECDIS)–Operational and performance requirements, methods of testing and required test results," applies to the interface in 5 above. But for recreational vessels? Is there an applicable standard? I looked at the specifications listed in the literature for my particular recreational-grade chart plotter, a Lowrance HDS-8, to see if there was a citation of any applicable IEC or other organization's standard. I only found citation of an IEC standard that seemed to apply to methods of construction of electronic equipment for a maritime environment, talking about use of stainless steel fasteners and water proofing, and not to matters of what sort of machine-to-machine interface the chart plotter would have with any DSC devices or the machine-to-human interface of the chart plotter to an operator with regard to displaying DSC distress alert messages. If anyone has any suggestions for reference material on this topic, I welcome their comments (via email, please).
The behavior of a typical recreational boat chart plotter to data sent to it from a DSC radio is examined in another article, Chart Plotter Interface in Digital Selective Calling.
This is a verified HTML 4.0 document served to you from continuousWave
Author: James W. Hebert
This article first appeared April 22, 2014.
A minor update was made in February 2021 to reflect the non-mandatory nature of position polling calls for Class-D DSC radios in the older ITU recommendations. In February 2022 an error was corrected in the analysis of the DSC message, and a new mention was made regarding Class-D features for position poling now being recommended in ITU REC.M-493-15.