IMPORTANT NOTE: The information contained in this document supersedes all previously
published information regarding this product. This manual is subject to change without prior notice.
About this Manual ...................................................................................................................................... v
Patents and Trademarks ............................................................................................................................ v
Product Support .......................................................................................................................................... v
This manual describes the installation and operation for the Radyne DMD Remote Operations.
This is a technical document intended for earth station engineers, technicians, and operators
responsible for the operation and maintenance of the Radyne DMD Remote Operations.
Patents and Trademarks
See all of Comtech EF Data’s Patents and Patents Pending at http://patents.comtechefdata.com.
Comtech EF Data acknowledges that all trademarks are the property of the trademark owners.
Product Support
For all product support, please call:
+1.240.243.1880
+1.866.472.3963 (toll free USA)
Preface
Military Standards
References to “MIL-STD-188” apply to the 114A series (i.e., MIL-STD-188-114A), which provides
electrical and functional characteristics of the unbalanced and balanced voltage digital interface
circuits applicable to both long haul and tactical communications. Specifically, these references
apply to the MIL-STD-188-114A electrical characteristics for a balanced voltage digital interface
circuit, Type 1 generator, for the full range of data rates. For more information, refer to the
Department of Defense (DOD) MIL-STD-188-114A, Electrical Characteristics of Digital Interface Circuits.
Related Documents
Department of Defense (DOD) MIL-STD-188-114A, Electrical Characteristics of Digital Interface
Circuits
Department of Defense (DOD) MIL-STD-188-165A, Interoperability and Performance Standards for
SHF Satellite Communications PSK Modems (FDMA Operation) (dated November 2005)
INTELSAT Earth Station Standards IESS-308, -309, -310, and -315
Applicable testing is routinely performed as a condition of manufacturing on all units to ensure
compliance with the requirements of the EN 60950 Safety of Information Technology Equipment (Including Electrical Business Machines) safety standard.
This equipment meets the Safety of Information Technology Equipment specification as defined
in EN60950.
Low Voltage Directive (LVD)
The following information is applicable for the European Low Voltage Directive (2006/95/EC):
Symbol Description
<HAR>
!
Type of power cord required for use in the European Community.
http://www.comtechefdata.com
Comtech EF Data Corp.
2114 West 7
Tempe, Arizona USA 85281
+1.480.333.2200
th
Street
MN-DMDREMOTEOP Revision 9 viii
Chapter 1. Remote Operations
1.1 Introduction
The Remote Protocols for the DMD20, DMD20LBST, DMD50, DMD2050, DMD2050E,
DMD1050 and OM20 are similar in design and utilize the same protocol platforms. This
document should be used as the primary source for identifying the various protocol structures
and control menus for products listed below. The most current Remote Protocols manual can be
accessed from the Radyne web site at http://www.comtechefdata.com
The Remote Protocols identified in MN-DMDREMOTEOP are RLLP (Radyne Link Level
Protocol), SNMP MIB file, Web Browser menus and Terminal Port menus. The MNDMDREMOTEOP document does not identify equipment setup processes. The Product manuals
include instructions to set up the equipment but will not include the protocol structure. The
Remote Protocol manual MN-DMDREMOTEOP is applicable to the following products:
The Remote Port allows for complete control and monitoring of all parameters and functions via
an RS-232 Serial Interface or RS-485 for RLLP Protocol. ‘Equipment Remote Mode’ can be
entered from the GUI interface under the “System” menu by selecting “System” and then
“Terminal” followed by “Terminal”. The baud rate and evaluation type can be changed at the front
panel by using the System>Baud Rate Menu.
Control and status messages are conveyed between the modem and all subsidiary modems and
the host computer using packetized message blocks in accordance with a proprietary
communications specification. This communication is handled by the Radyne Link Level Protocol
(RLLP), which serves as a protocol ‘wrapper’ for the RM&C data. Complete information on
monitor and control software is contained in the following sections.
This specification is applicable to the DMD20/20LBST, DMD50, DMD2050,
DMD2050E, DMD1050 and OM20 Modems. Any reference to the DMD20 in this
document can be applicable to any one of these three modems.
For configuration setup, refer to the product manuals.
1.2.1 Protocol Structure:
The Communications Specification (COMMSPEC) defines the interaction of computer resident
Monitor and Control Software used in satellite earth station equipment such as modems,
redundancy switches, multiplexers, and other ancillary support gear. Communication is bidirectional, and is normally established on one or more full-duplex 9600-baud multi-drop control
buses that conform to EIA Standard RS-485.
Each piece of earth station equipment on a control bus has a unique physical address, which is
assigned during station se tup/config uration or prior to ship ment. Valid dec imal addr esses on one
control bus range from 032 through 255 for a total of up to 224 devices per bus. Address 255 of
each control bus is usually reserved for the M&C computer.
1.2.2 Protocol Wrapper:
The Radyne COMMSPEC is byte-oriented, with the Least Significant Bit (LSB) issued first. Each
data byte is conveyed as mark/space information with two marks comprising the stop data. When
the last byte of data is transmitted, a hold comprises one steady mark (the last stop bit). To begin
or resume data transfer, a space (00h) substitutes this mark. This handling scheme is controlled
by the hardware and is transparent to the user. A pictorial representation of the data and its
surrounding overhead may be shown as follows:
S1 S2 B
0
The Stop Bits, S1 and S2, are each a mark. Data flow remains in a hold mode until S2 is
replaced by a space. If S2 is followed by a space, it is considered a start bit for the data byte and
not part of the actual data (B
Level Protocol (RLLP) organizes the actual monitor and control data within a shell, or ‘protocol
wrapper’ that surrounds the data. The format and structure of the COMMSPEC message
exchanges are described herein. Decimal numbers have no suffix; hexadecimal numbers end
with a lower case ‘h’ suffix and binary values have a lower case ‘b’ suffix. Thus, 22 = 16h =
000010110b. The principal elements of a data frame, in order of occurrence, are summariz ed as
follows:
<SYNC>: The message format header character or ASCII sync character that defines the
beginning of a message. The <SYNC> character value is always 16h.
<BYTE COUNT>: The Byte Count is the number of bytes in the <DATA> field (2 Bytes).
<SOURCE ID>: The Source Identifier defines the multi-drop addres s origin.
B1 B2 B3 B4 B5 B6 B7 S1 S2, etc.
0
- B 7). The COMMSPEC developed for use with the Radyne Link
All nodes on a given control bus have a unique address that must be defined.
<DESTINATION ID>: The Destination Identifier serves as a pointer to the multi-drop destination
device that indicates where the message is to be sent.
<FRAME SEQUENCE NUMBER>: The Frame Sequence Number (FSN) is a tag with a value
from 0 through 255 that is sent with each message. It assures sequential information
framing and correct equipment acknowledgment and data transfers.
<OPCODE>: The Operation Code field contains a number that identifies the message type
associated with the data that follows it. Equipment under MCS control recognizes this
byte via firmware identification and subsequently steers the DATA accordingly to perform
a specific function or series of functions. Acknowledgment and error codes are returned
in this field (2 Bytes).
<DATA>: The Data field contains the binary, bi-directional data bytes associated with the
<OPCODE>. The number of data bytes in this field is indicated by the <BYTE COUNT>
value.
<CHECKSUM>: The checksum is the modulo 256 sum of all preceding message bytes,
excluding the <SYNC> character. The checksum determines the presence or absence of
errors within the message. In a message block with the following parameters, the
checksum is computed as shown in Table 1-1.
Since the only concern is the modulo 256 (modulo 1 00h) equivalent (values that can be
represented by a single 8-bit byte), the checksum is F2h. For a decimal checksum calculation, the
equivalent values for each information field are:
In a Monitor and Control environment, every message frame on a control bus port executes as a
packet in a loop beginning with a wait-for-SYNC-character mode. The remaining message format
header information is then loaded, either by the M&C computer or by a subordinate piece of
equipment (such as the DMD20) requesting access to the bus. Data is processed in accordance
with the OPCODE, and the checksum for the frame is calculated. If the anticipated checksum
does not match, then a checksum error response is returned to the message frame originator.
The entire message frame is discarded and the wait-for-SYNC mode goes back into effect. If the
OPCODE resides within a command message, it defines the class of action that denotes an
instruction that is specific to the device type, and is a prefix to the DATA field if data is required. If
the OPCODE resides within a query message packet, then it defines the query code, and can
serve as a prefix to query code DATA.
The Frame Sequence Number (FSN) is included in every message packet and increments
sequentially. When the M&C computer or bus-linked equipment initiates a message, it assigns
the FSN as a tag for error control and handshaking. A different FSN is produced for each new
message from the FSN originator to a specific device on the control bus. If a command packet is
sent and not received at its intended destination, then an appropriate response message is not
received by the packet originator. The original command packet is then re-transmitted with the
same FSN. If the repeated message is received correctly at this point, it is considered a new
message and is executed and acknowledged as such.
If the command packet is received at its intended destination but the response message
(acknowledgment) is lost, then the message originator (usually the M&C computer) re-transmits
the original command packet with the same FSN. The destination device detects the same FSN
and recognizes that the message is a duplicate, so the associated commands within the packet
are not executed a second time. However, the response packet is again sent back to the source
as an acknowledgment in order to preclude undesired multiple executions of the same
command.
To reiterate, valid equipment responses to a message require the FSN tag in the command
packet. This serves as part of the handshake/acknowledges routine. If a valid response message
is absent, then the command is re-transmitted with the same FSN. For a repeat of the same
command involving iterative processes (such as increasing or decreasing the transmit power
level of a DMD20 modulator), the FSN is incremented after each message packet. When the
FSN value reaches 255, it overflows and begins again at zero. The FSN tag is a powerful tool
that assures sequential information framing, and is especially useful where commands require
more than one message packet.
The full handshake/acknowledgment involves a reversal of source and destination ID codes in
the next message frame, followed by a response code in the <OPCODE> field of the message
packet from the equipment under control.
If a command packet is sent and not received at its intended destination, a timeout condition can
occur because a response message is not received by the packet originator. On receiving
devices slaved to an M&C computer, the timeout delay parameters may be programmed into the
equipment in accordance with site requirements by Radyne prior to shipment, or altered by
qualified personnel. The FSN handshake routines must account for timeout delays and be able
to introduce them as well.
In acknowledgment (response) packets, the operational code <OPCODE> field of the message
packet is set to 0 by the receiving devices when the message intended for the device is
evaluated as valid. The device that receives the valid message then exchanges the <SOURCE
ID> with the <DESTINATION ID>, sets the <OPCODE> to zero in order to indicate that a good
message was received, and returns the packet to the originator. This "GOOD MESSAGE"
Opcode is one of nine global responses. Global response opcodes are common responses,
issued to the M&C computer or to another device that can originate from and are interpreted by
all Radyne equipment in the same manner. These are summarized as follows (all opcode values
are expressed in decimal form):
Response OPCODE Description OPCODE
Good Message 000d = 0000h
Bad Parameter 255d = 00FFh
Bad Opcode 254d = 00FEh
Incomplete Parameter 247d = 00F7h
Table 1-2: Response OPCODES
The following response error codes are specific to the DMD20:
When properly implemented, the physical and logical devices and ID addressing scheme of the
COMMSPEC normally precludes message packet contention on the control bus. The importance
of designating unique IDs for each device during station configuration cannot be
overemphasized. One pitfall, which is often overlooked, concerns multi-drop override IDs. All too
often, multiple devices of the same type are assigned in a direct-linked ("single-thread")
configuration accessible to the M&C computer directly.
For example, if two DMD20 Modems with different addresses (DESTINATION IDs) are linked to
the same control bus at the same hierarchical level, both will attempt to respond to the M&C
computer when the computer generates a multi-drop override ID of 22. If their actual setup
parameters, status, or internal timing differs, they will both attempt to respond to the override
simultaneously with different information or asynchronously in their respective message packets
and response packets, causing a collision on the serial control bus.
To preclude control bus data contention, different IDs must always be assigned to the
equipment. If two or more devices are configured for direct-linked operation, then the M&C
computer and all other devices configured in the same manner must be programmed to inhibit
broadcast of the corresponding multi-drop override ID.
The multi-drop override ID is always accepted by devices of the same type on a common control
bus, independent of the actual DESTINATION ID. These override IDs with the exception of
“BROADCAST” are responded to by all directly linked devices of the same type causing
contention on the bus. The “BROADCAST” ID, on the other hand, is accepted by all equipment
but none of then returns a response packet to the remote M&C.
The following multi-drop override IDs are device-type specific, with the exception of
"BROADCAST". These are summarized below with ID values expressed in decimal notation:
Directly-Addressed EquipmentMulti-Drop Override ID
Broadcast (all directly-linked devices) 00
DMD-3000/4000, 4500 or 5000 Mod Section, DMD20 01
DMD-3000/4000, 4500 or 5000 Demod Section, DMD20 02
RCU-340 1:1 Switch 03
RCS-780 1:N Switch 04
RMUX-340 Cross-Connect Multiplexer 05
CDS-780 Clock Distribution System 06
SOM-340 Second Order Multiplexer 07
DMD-4500/5000 Modulator Section 08
DMD-4500/5000 Demodulator Section 09
RCU-5000 M:N Switch 10
DMD20 Modulator 20
DMD20 Demodulator 21
DMD20 Modem 22
DVB3030 Video Modulator, DM240 23
RCS20 M:N Switch 24
RCS10 M:N Switch 25
RCS11 1:1 Switch 26
Reserved for future equipment types 27-31
Multi-drop override IDs 01 or 02 can be used interchangeably to broadcast a
message to a DMD-3000/4000 Modem, DMD-4500/5000, or a DMD20 Modem.
Radyne recommends that the multi-drop override IDs be issued only during
system configuration as a bus test tool by experienced programmers and that
they not be included in run-time software. It is also advantageous to consider
the use of multiple bus systems where warranted by a moderate to large
equipment complement.
Therefore, if a DMD20 Modulator is queried for its equipment type identifier, it will return a "20"
and DMD20 Demodulator will return a "21". A DMD20 Modem will also return a "22".
1.2.6 Software Compatibility:
The COMMSPEC, operating in conjunction within the RLLP shell, provides for full forward and
backward software compatibility independent of the software version in use. New features are
appended to the end of the DATA field without OPCODE changes. Older software simply
discards the data as extraneous information without functional impairment for backward
compatibility.
If new device-resident or M&C software receives a message related to an old software version,
new information and processes are not damaged or affected by the omission of data.
The implementation of forward and backward software compatibility often, but not always,
requires the addition of new Opcodes. Each new function requires a new Opcode assignment if
forward and backward compatibility cannot be attained by other means.
When Radyne equipment is queried for bulk information (Query Mod, Query Demod, etc.) it
responds by sending back two blocks of data; a Non-Volatile Section (parameters that can be
modified by the user) and a Volatile Section (status information). It also returns a count value that
indicates the size of the Non-Volatile Section. This count is used by M&C developers to index
into the start of the Volatile Section.
When new features are added to Radyne equipment, the control parameters are appended to
the end of the Non-Volatile Section, and status of the features, if any, are added at the end of the
Volatile Section. If a remote M&C queries two pieces of Radyne equipment with different revision
software, they may respond with two different sized packets. The remote M&C MUST make use
of the non-volatile count value to index to the start of the Volatile Section. If the remote M&C is
not aware of the newly added features to the Radyne product, it should disregard the parameters
at the end of the Non-Volatile Section and index to the start of the Volatile Section.
If packets are handled in this fashion, there will also be backward-compatibility between Radyne
equipment and M&C systems. Remote M&C systems need not be modified every time a feature
is added unless the user needs access to that feature.
1.2.7 Flow Control and Task Processing:
The original packet sender (the M&C computer) relies on accurate timeout information with
regard to each piece of equipment under its control. This provides for efficient bus
communication without unnecessary handshake overhead timing. One critical value is
designated the Inter-Frame Space (FS). The Inter-Frame Space provides a period of time in
which the packet receiver and medium (control bus and M&C computer interface) fully recover
from the packet transmission/reception process and the receiver is ready to accept a new
message. The programmed value of the Inter-Frame Space should be greater than the sum of
the "turnaround time" and the round-trip (sender/receiver/bus) propagation time, including
handshake overhead. The term "turnaround time" refers to the amount of time required for a
receiver to be re-enabled and ready to receive a packet after having just received a packet. In
flow control programming, the Inter-Frame Space may be determined empirically in accord with
the system configuration or calculated based on established maximum equipment task
processing times.
Each piece of supported equipment on the control bus executes a Radyne Link Level Task
(RLLT) in accordance with its internal hardware and fixed program structure. In a flow control
example, the RLLT issues an internal "message in" system call to invoke an I/O wait condition
that persists until the task receives a command from the M & C computer. The RLLT has the
option of setting a timeout on the incoming message. Thus, if the equipment does not receive an
information/command packet within a given time period, the associated RLLT exits the I/O wait
state and takes appropriate action.
Radyne equipment is logically linked to the control bus via an Internal I/O Processing Task
(IOPT) to handle frame sequencing, error checking, and handshaking. The IOPT is essentially a
link between the equipment RLLT and the control bus. Each time the M&C computer sends a
message packet; the IOPT receives the message and performs error checking. If errors are
absent, the IOPT passes the message to the equipment's RLLT. If the IOPT detects errors, it
appends error messages to the packet. Whenever an error occurs, the IOPT notes it and
discards the message; but it keeps track of the incoming packet. Once the packet is complete,
the IOPT conveys the appropriate message to the RLLT and invokes an I/O wait state (wait for
next <SYNC> character).
If the RLLT receives the packetized message from the sender before it times out, it checks for
any error messages appended by the IOPT. In the absence of errors, the RLLT processes the
received command sent via the transmitted packet and issues a "message out" system call to
ultimately acknowledge the received packet. This call generates the response packet conveyed
to the sender. If the IOPT sensed errors in the received packet and an RLLT timeout has not
occurred, the RLLT causes the equipment to issue the appropriate error message(s) in the
pending equipment response frame.
To maintain frame synchronization, the IOPT keeps track of error-laden packets and packets
intended for other equipment for the duration of each received packet. Once the packet is
complete, the IOPT invokes an I/O wait state and searches for the next <SYNC> character.
1.2.8 RLLP Summary:
The RLLP is a simple send-and-wait protocol that automatically re-transmits a packet whenever
an error is detected, or when an acknowledgment (response) packet is absent.
During transmission, the protocol wrapper surrounds the ac tual data to form information packets.
Each transmitted packet is subject to time out and frame sequence control parameters, after
which the packet sender waits for the receiver to convey its response. Once a receiver verifies
that a packet sent to it is in the correct sequence relative to the previously received packet, it
computes a local checksum on all information within the packet excluding the <SYNC> character
and the <CHECKSUM> fields. If this checksum matches the packet <CHECKSUM>, the receiver
processes the packet and responds to the packet sender with a valid response
(acknowledgment) packet. If the checksum values do not match, the receiver replies with a
negative acknowledgment (NAK) in its response frame.
The response packet is therefore an acknowledgment either that the message was received
correctly, or some form of a packetized NAK frame. If the sender receives a valid
acknowledgment (response) packet from the receiver, the <FSN> increments and the next
packet is transmitted as required by the sender. However, if a NAK response packet is returned
the sender re-transmits the original information packet with the same embedded <FSN>.
If an acknowledgment (response) packet or a NAK packet is lost, corrupted, or not issued due to
an error and is thereby not returned to the sender, the sender re-transmits the original
information packet; but with the same <FSN>. When the intended receiver detects a duplicate
packet, the packet is acknowledged with a response packet and internally discarded to preclude
undesired repetitive executions. If the M&C computer sends a command packet and the
corresponding response packet is lost due to a system or internal error, the computer times out
and re-transmits the same command packet with the same <FSN> to the same receiver and
waits once again for an acknowledgment or a NAK packet.
To reiterate, the format of the Link Level Protocol Message Block is shown below.
SYNC
Byte
Byte
COUNT
SOURCE
ADDRESS
DESTINATION
ADDRESS
FSN OPCODE
DATA
BYTES
CHECKSUM
1.3 Remote Port Packet Structure:
The Modem protocol is an enhancement on the DMD20 protocol. It also uses a packet structure
format. The structure is as follows:
<SYNC>: Message format header character that defines the beginning of a message. The
<SYNC> character value is always 0x16 (1 byte).
<BYTE COUNT>: The number of bytes in the <DATA> field (2 bytes).
<SOURCE ID>: Identifies the address of the equipment from where the message originated (1
byte).
<DESTINATION ID>: Identifies the address of the equipment where the message is to be sent (1
<FSN>: Frame sequence number ensures correct packet acknowledgment and data transfers (1
byte).
<OPCODE>: This byte identifies the message type associated with the information data. The
equipment processes the data according to the value in this field. Return error codes and
acknowledgment are also included in this field (2 bytes).
<...DATA...>: Information data. The number of data bytes in this field is indicated by the <BYTE
COUNT> value.
<CHECKSUM>: The modulo 256 sum of all preceding message bytes excluding the <SYNC>
character (1 byte).
The Modem RLLP is not software-compatible with the following previous
Radyne products: RCU5000 and DMD4500. These products may not occupy the
same bus while using this protocol as equipment malfunction and loss of data
may occur.
When transmitting a packet at 9600 baud, the Remote M&C should ensure that
the timeout value between characters does not exceed the time it takes to
transmit 200 characters (≈
200 msec). If this timeout value is exceeded, the
equipment will timeout.
1.4 DMD20 Opcode Command Set:
The DMD20/DMD20 LBST Opcode Command Set is listed below:
When new features are added to Radyne equipment, the control parameters
are appended to the end of the Non-Volatile Section of the Remote
Communications Specification, and status of the features, if any, are added at
the end of the Volatile Section. If a remote M & C queries two pieces of Radyne
equipment with different revision software, they could respond with two
different sized packets. The remote M & C MUST make use of the non-volatile
count value to index to the start of the Volatile Section. If the remote M & C is
not aware of the newly added features to the product, it should disregard the
parameters at the end of the Non-Volatile Section and index to the start of the
Volatile Section.
Before creating any software based on the information contained in this
document, contact the Comtech EF Data Customer Service Department (480333-4357) to find out if the software revision for that piece of equipment is
current and that no new features have been added since the release of this
document.
1.4.1 Modem Command Set:
Query Modulator Configuration and Status 2400h
Query Demodulator Configuration and Status 2401h
Query Modem Drop & Insert Map 2402h
Query Modems Identification 2403h
Query Modem Control Mode 2404h
Query Modulator Latched Alarms 2405h
Query Demodulator Latched Alarms 2406h
Query Modem Latched Alarms 2407h
Query Modulator Current Alarms 2408h
Query Demodulator Current Alarms 2409h
Query Modem Current Alarms 240Ah
Query Modulator Status 240Bh
Query Demodulator Status 240Ch
Query Modem Eb/No, BER and Level 240Dh
Query Time 240Eh
Query Date 240Fh
Query Time and Date 2410h
Query Modem Summary Faults 2411h
Query Modem Event Buffer 2412h
Query Modulator Configuration 2448h
Query Demodulator Configuration 2449h
Query Modem Features 2450h
Query Modulator Async Configuration 2451h
Query Demodulator Async Configuration 2452h
Query Up converter Configuration 2490h
Query Uplink RF 2491h
Query Down converter Configuration 2492h
Query Downlink RF 2493h
Query Demodulator Ethernet Terrestrial Interface Packet Status 2494h
Command Clear Latched Alarms 2C03h
Command Set Time 2C04h
Command Set Date 2C05h
Command Set Time and Date 2C06h
Clear Modem Common Latched Alarm 1 2C08h
Clear Modem Common Latched Alarm 2 2C09h
Command Delete Modem Event Buffer 2C0Ah
Command Soft Reset 2C0Bh
Command BUC FSK Pass Thru 2F61h
1.5 Detailed Command Descriptions:
1.5.1 DMD20 Modulator:
Opcode: <2400h> Query a Modulator's Configuration and Status
Loopback
<1> AUPC Remote 2047 0 = Disabled, 1 = Enabled
<2> AUPC Target Eb/No Target Eb/No at Receiver, 400 to 2000 (4.00 db to
20.00 db)
<2> AUPC Minimum
Power
For DMD20 Signed value 0 to –2500 with implied
decimal point; (0.00 to –25.00 dBm) (two’s compliment)
For OM20 Signed value -2000 to -4500 with implied
decimal point; (-20.00 to -45.00 dBm)
<2> AUPC Maximum
Power
For DMD20 Signed value 0 to –2500 with implied
decimal point; (0.00 to –25.00 dBm) (two’s compliment)
For OM20 Signed value -2000 to -4500 with implied
decimal point; (-20.00 to -45.00 dBm)
<2> AUPC Nominal
Power
For DMD20 Signed value 0 to –2500 with implied
decimal point; (0.00 to –25.00 dBm) (two’s compliment)
For OM20 Signed value -2000 to -4500 with implied