continuousWave --> Whaler --> Reference --> Data Interface in Digital Selective Calling Class-D Radios

Data Interface in Digital Selective Calling Class-D Radios

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:

Digital Selective Calling Methods

Radio and Data Link

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.

Symbol Encoding

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: the symbols from 00 to 99 are used to code two decimal figures according to Table 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.

Details of a Call Sequence

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.

Call Content

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:

Format Specifier

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.

Message Elements

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.

Message Elements for Call of DISTRESS Format Per Table 4.1

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):

  1. Nature of Distress
  2. Distress Coordinates
  3. Time in UTC
  4. Type of communication preferred for subsequent traffic

Nature of Distress

Nature of Distress is to be encoded, again using Table 3, as follows

Distress Coordinate

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.

Time in UTC

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.

Type of Communication Preferred

Since digital selective calling is often used to set up another call, this message element gives the preference for follow-on communication modes.

Assembling All Elements Into a Call

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.

Example of Distress Alert

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:


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:

  1. $CDDSC indicates a datagram from a Communiction device, with specific type Digital selective calling, and sent in a datagram format called DSC; this is all based on prior explanations of the general format of IEC-61126 from public resources. This is great! We have output on the data link that corresponds to a DSC call, which is precisely what was anticipated.
  2. 12--Now we look to ITU-Rec M.493 to see what is contained in the call content, as we presume this element of the message and the ones that follow must be some encoding of data included in the call content. Since we anticipate the first element of the call content to be a format specifier, we presume "12" is a format specifier code. However, the encoding does not correspond to ITU-Rec. M.493-13, where three digits are specified for encoding of a symbol used as a service command (or data about the data); this wired link encoding only uses two digits. By comparing the encoding "12" with the ITU-Rec. M-493.13 list of encodings, we see that the format specifier is a three digit code, but the first digit is always "1". Since we think this encoding is representative of a distress alert message format specifier, we assume that the leading "1" is omitted on the data link message, and that in this encoding we can assume "12" is the equivalent of Symbol 112. This means the message format specifier is "distress alert call". This seems like a reasonable assumption, and we proceed on that basis.
  3. 3380400790 is clearly the encoding of the MMSI associated with my Radio A, which sent the message. This corresponds with the ITU-Rec. M.493-13 element called "self-identity."
  4. 12 is likely to be the category element. Again, the category elements are to be represented by three digits, and we have only two. But, again, there is excellent correlation if we ignore the leading "1" in the ITU recommendation. We interpret "12" as if it were "112" from the ITU Table 4, and find this category is "distress." Knowing we have a distress alert message of category distress, we now consider the remaining elements of the data link message with an eye to how they correspond with the ITU message elements for a call of format specifier distress and category distress. That format is shown in Table 4.1.
  5. 06 looks like an encoding of Nature of Distress. This is readily deduced by sending a few test calls with different elements for nature of distress and observing what changes in the wired data link datagram. Again, we have only two digits when the ITU specified a three-digit symbol. Interpreting "06" as "106" in ITU Table 3 gives nature of distress as "adrift." In this case, "adrift" is correct, as that is what was sent.
  6. 00 is confusing. I was expecting it to be the distress coordinate, based on the sequence used in the radio transmission, but clearly it is not. It is also not the time. This leaves only the the type of communication preferred. This is also given in Table 3. Using the now apparent conversion of two-digits to three, "00" is interpreted as "100", giving F3E/G3E (i.e., frequency- or phase-modulated radiotelephony).
  7. 1423108312 looks like the position, which is interpreted as 42-degrees 31-minutes latitude, 083-degrees 12-minutes longitude, in North and West. Excellent! That was the position of the vessel that sent the message.
  8. 2019 appears to be the time in UTC, 20-hours, 19-minutes. Again, we have excellent correlation, as the message was sent at 2019-UTC.
  9. Since there was no data in this element of the datagram, there is no meaning or interpretation possible. If subsequent test message transmission reveal some content in this position, it may be possible to draw an inference. This portion of the datagram may be used in messages of another type. It does not appear to be used in reception of a distress alert message.
  10. Since there was no data in this element of the datagram, there is no meaning or interpretation possible. If subsequent test message transmission reveal some content in this position, it may be possible to draw an inference. This portion of the datagram may be used in messages of another type. It does not appear to be used in reception of a distress alert message.
  11. S is difficult to interpret. It may be a representation of a service command per Table 3 that is listed as a "unique function" code, and possibly Symbol 127 for EOS or "end of Sequence." Collection of more examples and further study will be needed.
  12. E is interpreted to mean that an expansion message will follow, as described in ITU-Rec. M.821. This lets the connected device know to look for the next datagram to be an expansion message, which will give the position with decimal portions of minutes.
  13. *2F is a checksum. The IEC-61162 method apparently also requires inclusion of an error-checking characters.

Sending of Command Code Symbols 100 to 127

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.

Simplified Table 3

After a similar table in ITU-Rec. M.493-13. Caution: some values omitted for clarity!
Encoding in DSC radio data link output
00 RoutineFire, explosion
08SafetyAbandoning ship
10UrgencyMan overboard
12DistressDistressEPIRB Emission

End of Sequence Signals

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".

Interpretation of Datagram

To summarize the content of the datagram being analyzed, it is a digital selective calling message:

Example of Distress Alert Cancel

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:


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
  1. $CDDSC--from a DSC radio.
  2. 12--distress alert call.
  3. 3381581370--the MMSI of the sender.
  4. 12--category is "distress."
  5. 06--Nature of Distress is"adrift."
  6. 00--preferred follow-on communication by frequency- or phase-modulated simplex radio telephony.
  7. 1423108312--position, which 42-degrees 31-minutes latitude, 083-degrees 12-minutes longitude, in North and West.
  8. 0236--message was sent at 0236-UTC.
  9. 3381581370--now the new information! This is a repeat of the MMSI of the sender. Since I know this datagram comes from receiving a distress alert cancelation message, the repetition of the same MMSI in this field as in the sender's field must be significant. In ITU-Rec. M.493-13, in Table 4.2 there is a footnote, which says, "Distress acknowledgments where the transmitting MMSI and ship in distress MMSI are the same, the message should be interpreted as a self Cancel operation." This sheds light on the nature of this field. This field must be "the address of vessel in distress" if the message is a distress acknowledgement message.
  10. [null]--still no signal in this field.
  11. S--end of sequence.
  12. [null]--no expansion message to follow since no "E" here.
  13. *20--checksum.

Interpretation of Datagram

To summarize the content of the datagram being analyzed, it is a digital selective calling message:

Example of Non-Distress Call

Reply to Position Request

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
  1. $CDDSC--from a DSC radio.
  2. 20--call format or type is "individual."
  3. 3381581370--the MMSI of the sender.
  4. 00--category is "routine."
  5. 21--(see below).
  6. 26--(see below).
  7. 1423108312--position, 42-31-N, 083-12-West.
  8. 1902--sent at 1902-UTC.
  9. [null]--(apparently not need for this type of message.)
  10. [null]--(apparently not need for this type of message.)
  11. B--acknowledge Back (end of sequence)
  12. E--an expansion message to follow.
  13. *20--checksum.

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:

Simplified Table 3 Telecommands

After a similar table in ITU-Rec. M.493-13. Caution: some values omitted for clarity!
Encoding in DSC radio data link output for non-distress calls
00 F3E/G3E All modeNo reason given
01F3E/G3E DuplexCongestion...
03PollingQueue indication
04Unable to complyStation barred
05End of callNo operator available
06DataOperator temporarily unavailable
07Equipment disabled
08Unable to use proposed channel
09J3E telephonyUnable to use proposed mode
10Distress Acknowledgement(Weird--see original)
11Medical transports
12Distress RelayPay-phone/public call office
13F1B/J2B TTY-FECFacsimile
21Ship position
26No informationNo information

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.

Interpretation of Datagram

To summarize the content of the datagram being analyzed, it is a digital selective calling message:

Example of Expansion 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":

After a similar table in ITU-Rec. M.821-1.
Symbols for expansion data specifiers
SymbolExpansion data specifier
00Enhanced position resolution
01Source of datum of position
02Current speed of the vessel
03Current course of the vessel
04Additional station identification
05Enhanced geographic area
06Number 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
  1. $CDDSE--from a DSC radio. Since this followed a datagram that indicated an expansion message would follow, this datagram is a representation on the wired data link of that DSC expansion message.
  2. 1--based on similar coding seen in other datagrams, this field is likely to indicate the total number of datagrams that are part of this expansion message.
  3. 1--as suggested above, this is likely the number of this datagram in the message sequence. Since this is one of a total of one, this datagram contains all the data for the expansion message.
  4. A--to be determined.
  5. 3380400790--a ten-digit representation of the sender's MMSI.
  6. 00--this field of two-digits appears to be the expansion data specifier described in Table 1 of ITU-Rec.M821-1, but with the symbol representation in two-digits instead of three-digits. The leading "1" seems to not be used. (See modified table, above.) This field identifies the data that will follow in the next field. In this message, the data will be "enhanced position resolution."
  7. 45894494--the data payload, which is eight digits. The first four are the decimal portion of the latitude minutes; the last four are the decimal portion of the longitude minutes. The latitude and longitude whole minutes were sent in the immediately preceding datagram. This is as specified in the ITU-Rec. M.821-1 in section
  8. *1B--checksum.

General Format of NMEA Message DSC

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
  1. $CDDSC--from a Communication device of type DSC, message type DSC
  2. aa--call type: according to
  3. bbbbbbbbb0--the 9-digit MMSI of the sender with an added zero
  4. cc--category: according to
  5. dd--depending on message type; if distress alert, then nature of distress according to or first "telecommand" (see simplified Table 3 above)
  6. ee--depending on the message type; if distress alert, then subsequent communication mode according toor "second telecommand" (see simplified Table 3 above) or
  7. fgghhiiijj--position: according to or channel identifier or frequency (of subsequent communication)
  8. kkkk--time of message in UTC.
  9. [null]--(not determined yet; unlikely in Class D radios)
  10. [null]--(not determined yet; unlikely in Class D radios)
  11. m--end of message: according to
  12. n--E indicates expansion message to follow immediately
  13. *xx--checksum of two digits preceded by *

Limitation of Class-D DSC Radios

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.

Calls Initiated on Class-D Radio

The Class-D radio can only send a few types of calls. These fall into two categories: distress calls and non-distress calls.

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.

Non-distress Calls

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.

Calls Received on Class-D Radios

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:

  1. a distress alert call;
  2. a distress alert cancel call; and,
  3. a position request acknowledge back call.

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.

The Interface Between Human and Machine

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:

Simplified Flow Chart of Distress Alert Signal

  1. Human–Machine Interface: operator composes messages and initiates transmission via radio. ITU-Rec. M.493-13 applies.
  2. Machine–Machine Interface: two radios communicate, one transmitting the message, and the second receiving the message. ITU-Rec. M.493-13 applies.
  3. Machine–Human Interface: receiving radio presents message to operator. ITU-Rec. M.493-13 applies.
  4. Machine–Machine Interface: receiving radio sends data to another navigation device, an electronic chart and information system (ECDIS) or similar, over wired data link. IEC-61162 applies.
  5. Machine–Human Interface: ECDIS device or chart plotter receives data from radio, and presents message to operator. What standard applies?

Presentation of DSC Distress Alert Calls on Chart or Information Displays

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.

Valid HTML 4.01 Transitional

Valid CSS!