MIL-STD-1553

Complete Online Resource

Notice II

1.0 Military Standard

CHANGE NOTICES ARE NOT CUMULATIVE                                                                                                                                                                MIL-STD-1553B
AND SHALL BE RETAINED UNTIL SUCH                                                                                                                                                                      NOTICE 2
TIME AS THE ENTIRE STANDARD IS                                                                                                                                                                             8 September 1986
REVISED. 

          
MILITARY STANDARD
DIGITAL TIME DIVISION
COMMAND/RESPONSE MULTIPLEX DATA BUS

 

TO ALL HOLDERS OF MIL-STD-1553B:

1.  MAKE THE FOLLOWING PEN AND INK CHANGES:

Page i

Delete title and substitute: “DIGITAL TIME DIVISION COMMAND/RESPONSE MULTIPLEX DATA BUS”.

Page ii

Delete title and substitute: “Digital Time Division Command/Response Multiplex Data Bus”.

Page 1

Paragraph 1.1, second line: Delete “on aircraft”.
Paragraph 1.2, third line: Delete “an aircraft” and substitute “a”.

Page 3

Paragraph 3.11, first line, after “Bus controller”: Insert “(BC)”.
Paragraph 3.12, first line, after “Bus monitor”: Insert “(BM)”.

Page 21

Paragraph 4.4.3.1, add: “No combination of RT address bits, T/R bit, subaddress/mode bits, and data word count/mode code bits of a command word shall result in invalid transmissions by the RT. Subsequent valid commands shall be properly responded to by the RT.”

Page 30

Paragraph 4.6.3.2, first line: Delete “Reset data bus transmitter” and substitute “Superseding valid commands”.
Paragraph 4.6.3.2, second line: Delete “from either data bus” and substitute “from the other data bus”.

Page 31

Paragraph 10.2, eighth line: Delete “airborn”.

2. THE FOLLOWING PAGES OF MIL-STD-1553B HAVE BEEN REVISED AND SUPERSEDE
     THE PAGES LISTED:

New Page Date Superseded Page Date
iii 8 September 1986 iii 12 February 1980
iv 8 September 1986 iv 21 September 1978
vii 8 September 1986 vii 21 September 1978
viii 8 September 1986 viii 12 February 1980
viiia 8 September 1986 viiia 12 February 1980
33 21 September 1978 33 Reprinted without change
34 8 September 1986 34 12 February 1980
35 8 September 1986 35 12 February 1980
36 8 September 1986 Inital Publication
37 8 September 1986 Inital Publication
38 8 September 1986 Inital Publication

3. RETAIN THIS NOTICE AND INSERT BEFORE TABLE OF CONTENTS.

4. Holders of MIL-STD-1553B will verify that page changes and additions indicated above
     have been entered. This notice page will be retained as a check sheet. This issuance,
     together with appended pages, is a separate publication. Each notice is to be retained by
     stocking points until the military standard is completely revised or cancelled.

 Custodians:                                                                                                                 Preparing activity:
 Army – ER                                                                                                                   Air Force – 11
 Navy – AS
 Air Force – 11                                                                                                            Project No. MCCR-0008

FSC MCCR
DISTRIBUTION STATEMENT A.
Approved for public release;
distribution is unlimited

2.0 Foreword

 

This standard contains requirements for a digital time division command/response multiplex data bus for use in systems integration. Even with the use of this standard, differences may exist between multiplex data buses in different system applications due to particular application requirements and the designer options allowed in this standard. The system designer must recognize this fact and design the multiplex bus controller hardware and software to accommodate such differences. These designer selected options must exist to  allow the necessary flexibility in the design of specific multiplex systems in order to provide for the control mechanism, architectural redundancy, degradation concept and traffic patterns peculiar to the specific application requirements. Appendix, Section 30 selects those options which shall be required and further restricts certain portions of the standard for the use in all dual standby redundant applications for the Army, Navy, and Air Force.
Supersedes page iii dated 12 February 1980.  

3.0 Content - Part 1

Paragraph
or Figure
 
Spec Page
Web Page Section Number
1. SCOPE
1
Review and Rationale of
MIL-STD-1553 A and B
1.0
1.1 Scope
1
Review and Rationale of MIL-STD-1553 A and B 1.0
1.2 Application
1
Review and Rationale of MIL-STD-1553 A and B 1.1
2. REFERENCED DOCUMENTS
1
Review and Rationale of MIL-STD-1553 A and B 2.0
2.1 Issue of Document
1
Review and Rationale of MIL-STD-1553 A and B 2.1
3. DEFINITIONS
1
Review and Rationale of MIL-STD-1553 A and B 3.0
3.1 Bit
1
Review and Rationale of MIL-STD-1553 A and B 3.1
3.2 Bit Rate
1
Review and Rationale of MIL-STD-1553 A and B 3.2
3.3 Pulse Code Modulation (PCM)
1
Review and Rationale of MIL-STD-1553 A and B 3.3
3.4 Time Division Multiplexing (TDM)
1
Review and Rationale of MIL-STD-1553 A and B 3.4
3.5 Half Duplex
1
Review and Rationale of MIL-STD-1553 A and B 3.5
3.6 World
1
Review and Rationale of MIL-STD-1553 A and B 3.6
3.7 Message
3
Review and Rationale of MIL-STD-1553 A and B 3.7
3.8
Subsystem
3
Review and Rationale of MIL-STD-1553 A and B 3.8
3.9 Data Bus
3
Review and Rationale of MIL-STD-1553 A and B 3.9
3.10 Terminal
3
Review and Rationale of MIL-STD-1553 A and B 3.10
3.11
Bus Controller (BC)
3
Review and Rationale of MIL-STD-1553 A and B 3.11
3.12 Bus Monitor (BM)
3
Review and Rationale of MIL-STD-1553 A and B 3.12
3.13 Remote Terminal (RT)
3
Review and Rationale of MIL-STD-1553 A and B 3.13
3.14 Asynchronous Operation
3
Review and Rationale of MIL-STD-1553 A and B 3.14
3.15 Dynamic Bus Control
3
Review and Rationale of MIL-STD-1553 A and B 3.15
3.16 Command/Response
3
Review and Rationale of MIL-STD-1553 A and B 3.16
3.17 Redundant Data Bus
3
Review and Rationale of MIL-STD-1553 A and B 3.17
3.18 Broadcast
3
Review and Rationale of MIL-STD-1553 A and B 3.18

3.0 Content - Part 2

3.19 Mode Code
3
Review and Rationale of MIL-STD-1553 A and B 3.19
4. GENERAL REQUIREMENTS
4
Review and Rationale of MIL-STD-1553 A and B 4.0
4.1 Test and Operating Requirements
4
Review and Rationale of MIL-STD-1553 A and B 4.1
4.2 Data Bus Operation
4
Review and Rationale of MIL-STD-1553 A and B 4.2
4.3 Characteristics
4
Review and Rationale of MIL-STD-1553 A and B 4.3
4.3.1 Data Form
4
Review and Rationale of MIL-STD-1553 A and B 4.3.1
4.3.2 Bit Priority
4
Review and Rationale of MIL-STD-1553 A and B 4.3.2
4.3.3 Transmission Method
4
Review and Rationale of MIL-STD-1553 A and B 4.3.3
4.3.3.1 Modulation
4
Review and Rationale of MIL-STD-1553 A and B 4.3.3.1
4.3.3.2 Data Code
4
Review and Rationale of MIL-STD-1553 A and B 4.3.3.2
4.3.3.3 Transmission Bit Rate
4
Review and Rationale of MIL-STD-1553 A and B 4.3.3.3
4.3.3.4 Word Size
4
Review and Rationale of MIL-STD-1553 A and B 4.3.3.4
4.3.3.5 Word Formats
4
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5
4.3.3.5.1 Command Word
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1
4.3.3.5.1.1 Sync
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.1
4.3.3.5.1.2 Remote Terminal Address
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.2
4.3.3.5.1.3 Transmit/Receive
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.3
4.3.3.5.1.4 Subaddress/Mode
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.4
4.3.3.5.1.5 Data Word Count/Mode Count
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.5
4.3.3.5.1.6 Parity
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.6
4.3.3.5.1.7 Optional Mode Control
8
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.7
4.3.3.5.1.7.1 Dynamic Bus Control
9
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.7.1
4.5.2.2.1.3 Output Noise
29
Review and Rationale of MIL-STD-1553 A and B 4.5.2.2.1.3
4.5.2.2.1.4 Output Symmetry
29
Review and Rationale of MIL-STD-1553 A and B 4.5.2.2.1.4

3.0 Content - Part 3

4.5.2.2.2 Terminal Input Characteristics
29
Review and Rationale of MIL-STD-1553 A and B 4.5.2.2.2
4.5.2.2.2.1 Input Waveform Compatibility
29
Review and Rationale of MIL-STD-1553 A and B 4.5.2.2.2.1
4.5.2.2.2.2 Common Mode Rejection
29
Review and Rationale of MIL-STD-1553 A and B 4.5.2.2.2.2
4.5.2.2.2.3 Input Impedance
29
Review and Rationale of MIL-STD-1553 A and B 4.5.2.2.2.3
4.5.2.2.2.4 Noise Rejection
29
Review and Rationale of MIL-STD-1553 A and B 4.5.2.2.2.4
4.6 Redundant Data Bus Requirement
30
Review and Rationale of MIL-STD-1553 A and B 4.6
4.6.1 Electircal Isolation
30
Review and Rationale of MIL-STD-1553 A and B 4.6.1
4.6.2 Single Event Failure
30
Review and Rationale of MIL-STD-1553 A and B 4.6.2
4.6.3 Dual Standby Redundant Data Bus
30
Review and Rationale of MIL-STD-1553 A and B 4.6.3
4.6.3.1 Data Bus Activity
30
Review and Rationale of MIL-STD-1553 A and B 4.6.3.1
4.6.3.2 Superseding Valid Commands
30
Review and Rationale of MIL-STD-1553 A and B N/A
5. DETAIL REQUIREMENTS
30
Review and Rationale of MIL-STD-1553 A and B 5.0
 
FIGURES
     
1 Sample Multiplex Data Bus Architecture
2
Review and Rationale of MIL-STD-1553 A and B 2.1
2 Data Encoding
5
Review and Rationale of MIL-STD-1553 A and B 4.3.3.2
3 Word Formats
6
Review and Rationale of MIL-STD-1553 A and B 4.3.3.4
4 Command and Status Sync
7
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.2
5 Data Sync
7
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.2.1
6 Information Transfer Formats
15
Review and Rationale of MIL-STD-1553 A and B 4.3.3.6
7 Broadcast Information Transfer Formats
16
Review and Rationale of MIL-STD-1553 A and B 4.3.3.6
8 Intermessage Gap and Response Time
18
Review and Rationale of MIL-STD-1553 A and B 4.3.3.8
9 Data Bus Interface Using Transfomer Coupling
19
Review and Rationale of MIL-STD-1553 A and B 4.3.3.8

3.0 Content - Part 4

10 Data Bus Interface Using Direct Coupling
20
Review and Rationale of MIL-STD-1553 A and B 4.3.3.9
11 Coupling Transformer
24
Review and Rationale of MIL-STD-1553 A and B 4.5.1.5.1.1.2
12 Terminal I/O Characteristics for Transformer Coupled and Direct Coupled Stubs
24
Review and Rationale of MIL-STD-1553 A and B 4.5.2.1.1.2
13 Output Waveform
26
Review and Rationale of MIL-STD-1553 A and B 4.5.2.1.2.4
 
TABLES
     
I Assigned Mode Codes
10
Review and Rationale of MIL-STD-1553 A and B 4.3.3.5.1.7
II Criteria for Acceptance or Rejection of a Terminal for the Noise Rejection Test
28
Review and Rationale of MIL-STD-1553 A and B 4.5.2.1.2.4
 
APPENDIX
     
10 General
31
Review and Rationale of MIL-STD-1553 A and B 5.1
10.1 Redundancy
31
Review and Rationale of MIL-STD-1553 A and B 5.2
10.2 Bus Controller
31
Review and Rationale of MIL-STD-1553 A and B 5.3
10.3 Multiplex Selection Criteria
33
Notice II 3 10.3
10.4 High Reliability Requirements
33
Notice II 3 10.4
10.5 Stubbing
33
Notice II 3 10.5
10.6 Use of Broadcast Option
34
Notice II 3 10.6
10.7 Other Releated Documents 34 Notice II 3 10.7
20. REFERENCED DOCUMENTS 34 Notice II 3 20.
30. GENERAL REQUIREMENTS 34 Notice II 3 30.
30.1 Option Selection 34 Notice II 3 30.1
30.2 Application 34 Notice II 3 30.2
30.3 Unique Address 34 Notice II 3 30.3
30.4 Mode Codes 35 Notice II 3 30.4

3.0 Content - Part 5

30.4.1 Subaddress/Mode 35 Notice II 3 30.4.1
30.4.2 Required Mode Codes 35 Notice II 3 30.4.2
30.4.2.1 Remote Terminal Required Mode Codes 35 Notice II 3 30.4.2.1
30.4.2.2 Bus Controller Required Mode Codes 35 Notice II 3 30.4.2.2
30.4.3 Reset Remote Terminal 35 Notice II 3 30.4.3
30.4.4 Initiate RT Self Test 35 Notice II 3 30.4.4
30.5 Status Word Bits 36 Notice II 3 30.5
30.5.1 Information Content 36 Notice II 3 30.5.1
30.5.2 Status Bit Requirements 36 Notice II 3 30.5.2
30.5.3 Busy Bit 36 Notice II 3 30.5.3
30.6 Broadcast 36 Notice II 3 30.6
30.7 Data Wrap-around 37 Notice II 3 30.7
30.8 Message Formats 37 Notice II 3 30.8
30.9 RT to RT Validation 37 Notice II 3 30.9
30.10 Electical Characteristics 37 Notice II 3 30.10
30.10.1 Cable Shielding 37 Notice II 3 30.10.1
30.10.2 Shielding 37 Notice II 3 30.10.2
30.10.3 Connector Polarity 37 Notice II 3 30.10.3
30.10.4 Characteristic Impedance 37 Notice II 3 30.10.4
30.10.5 Stub Coupling 38 Notice II 3 30.10.5
30.10.6 Power On/Off Noise 38 Notice II 3 30.10.6
  APPENDIX FIGURES      
10.1 Illustration of Possible Redundancy
32
Review and Rationale of MIL-STD-1553 A and B 5.2
10.2 Illustration of Possible Redundancy
32
Review and Rationale of MIL-STD-1553 A and B 5.2

3.0 Content - Part 6

 Supersedes  dated 12 February 1980.

10.3 Multiplex selection criteria. The selection of candidate signals for multiplexing is a function of the particular application involved, and criteria will in general vary from system to system. Obviously, those signals which have bandwidths of 400 Hz or less are prime candidates for inclusion on the bus. It ia also obvious that video, audio, and high speed parallel digital signals should be excluded. The area of questionable application is usually between 400 Hz and 3 Khz bandwidth. The transfer of these signals on the data bus will depend heavily upon the loading of the bus in a particular application. The decision must be based on projected future bus needs as well as the current loading. Another class of signals which in general are not suitable for multiplexing are those which can be typified by a low rate (over a mission) but possessing a high priority or urgency. Examples of such signals might be a nuclear event detector output or a missile launch alarm from a warning receiver. Such signals are usually better left hardwired, but they may be accommodated by the multiplex system if a direct connection to the bus controller’s interrupt hardware is used to trigger a software action in response to the signal.

10.4 High reliability requirements. The use of simple parity for error detection within the multiplex bus system was dictated by a compromise between the need for reliable data transmission, system overhead, and remote terminal simplicity. Theoretical and empirical evidence indicates that an undetected bit error rate of 10-12 can be expected from a practical multiplex system built to this standard. If a particular signal requires a bit error rate which is better than that provided by the parity checking, then it is incumbent upon the system designer to provide the reliability within the constraints of the standard or to not include this signal within the multiplex bus system. A possible approach in this case would be to have the signal source and sink provide appropriate error detection and correction encoding/decoding and employ extra data words to transfer the information. Another approach would be to partition the message, transmit a portion at a time, and then verify by interrogation) the proper transfer of each segment.

10.5 Stubbing. Stubbing is the method wherein a separate line is connected between the primary data bus line and a terminal. The direct connection of a stub line causes a mismatch which appears on the waveforms. This mismatch can be reduced by filtering at the receiver and by using bi-phase modulation. Stubs are often employed not only as a convenience in bus layout but as a means of coupling a unit to the line in such a manner that a fault on the stub or terminal will not greatly affect the transmission line operation. In this case, a network is employed in the stub line to provide isolation from the fault. These networks are also used for stubs that are of such length that the mismatch and reflection degrades bus operation. The preferred method of stubbing is to use transformer coupled stubs, as defined in 4.5.1.5.1. This method provides the benefits of DC isolation, Increased common mode protection, a doubling of effective stub impedance, and fault isolation for the entire stub and terminal. Direct coupled stubs, as defined in 4.5.1.5.2 of this standard, should be avoided if at all possible. Direct coupled stubs provide no DC isolation or common mode rejection for the terminal external to its subsystem.

Further, any shorting fault between the subsystems internal isolation resistors(usually on a circuit board) and the main bus junction will cause failure of that entire bus. It can be expected that when the direct coupled stub length exceeds 1.6 feet, that it will begin to distort the main bus waveforms. Note that this length includes the cable runs internal to a given subsystem.

*10.6 Use of broadcast option. The use of a broadcast message as defined in 4.3.3.6.7 of this standard represents a significant departure from the basic philosophy of this standard in that it is a message format which does not provide positive closed-loop control of bus traffic. The system designer is strongly encouraged to solve any design problems through the use of the three basic message formats without resorting to use of the broadcast option. If system designers do choose to use the broadcast command, they should carefully consider the potential effects of a missed broadcast message, and the subsequent implications for fault or error recovery design in the remote terminals and bus controllers.

*10.7 Other related documents. Several documents exist which are related to this standard. MIL-HDBK-1553 describes implementation practices for this standard and other related data. This standard is embodied in or referenced by the following international documents: NATO STANAG 3838, ASCC Air Standard 50/2, and UK DEF STAN 00-18 (PART 2)/Issue 1.

*20. REFERENCED DOCUMENTS
Not applicable.

*30. GENERAL REQUIREMENTS

*30.1 Option selection. This section of the appendix shall select those options required to further define portions of the standard to enhance triservice interoperability. References in parentheses are to paragraphs in this standard which are affected.

*30.2 Application. Section 30 of this appendix shall apply to all dual standby redundant applications for the Army, Navy, and Air Force. All Air Force aircraft internal avionics applications shall be dual standby redundant, except where safety critical or flight critical requirements dictate a higher level of redundancy.

*30.3 Unique address (4.3.3.5.1.2). All remote terminals shall be capable of being assigned any unique address from decimal address 0 (00000) through decimal address 30 (11110). The address shall be established through an external connector, which is part of the system wiring and connects to the remote terminal. Changing the unique address of a remote terminal shall not require the physical modification or manipulation of any part of the remote terminal. The remote terminal shall, as a minimum, determine and validate its address during power-up conditions. No single point failure shall cause a terminal to validate a false address. The remote terminal shall not respond to any messages if it has determined its unique address is not valid.

 *30.4 Mode codes (4.3.3.5.1.7)

*30.4.1 Subaddress/mode (4,3.3.5.1.4). An RT shall have the capability to respond to mode codes with both subaddress/mode of 00000 and 11111. Bus controllers shall have the capability to issue mode commands with both subaddress/mode of 00000 and 11111. The subaddress/mode of 00000 and 11111 shall not convey different information.

*30.4.2 Required mode codes (4.3.3.5.1.7)

3.0 Content - Part 7

*30.4.2.1 Remote terminal required mode codes. An RT shall implement the following mode codes as a minimum:

Mode Code
Function
00010 Transmit Status Word
00100 Transmitter Shutdown
00101 Override Transmitter Shutdown
01000 Reset Remote Terminal

 *30.4.2.2 Bus controller required mode codes. The bus controller shall have the capability to implement all of the mode codes as defined in 4.3.3.5.1.7. For Air Force applications, the dynamic bus control mode command shall never be issued by the bus controller.

*30.4.3 Reset remote terminal (4.3.3.5.1.7.9). An RT receiving the reset remote terminal mode code shall respond with a status word as specified in 4.3.3.5.1.7.9 and then react. While the RT is being reset, the RT shall respond to a valid command with any of the following: no response on eitherdata bus, status word transmitted with the busy bit set, or normal response. If any data is transmitted from the RT while it is being reset, the information content of the data shall be valid. An RT receiving this mode code shallcomplete the reset function within 5.0 milliseconds following transmission of the status word specified in 4.3.3.5.1.7.9. The time shall be measured from the mid-bit zero crossing of the parity bit of the status word to the mid-sync zero crossing of the command word at point A on figures 9 and 10.

*30.4.4 Initiate RT self test (4.3.3.5.1.7.4). If the initiate self test mode command is implemented in the RT, then the RT receiving the initiate self test mode code shall respond with a status word as specified in 4.3.3.5.1.7.4 and then initiate the RT self test function. Subsequent valid commands may terminate the self-test function. While the RT self test is in progress, the RT shall respond to a valid command with any of the following: no response on either data bus, status word transmitted with the busy bit set, or normal response. If any data is transmitted from the RT while it is in self test, the information content of the data shall be valid. An RT receiving this mode code shall complete the self test function and have the results of the self test available within 100.0 milliseconds following transmission of the status word specified in 4.3.3.5.1.7.4, The time shall be measured from the mid-bit zero crossing of the parity bit of the status word to the mid-sync zero crossing of the command word at point A on figures 9 and 10.

*30.5 Status word bits (4.3.3.5.3)

*30.5.1 Information content. The status word transmitted by an RT shall contain valid information at all times, e.g., following RT power up, during initialization, and during normal operation.

*30.5.2 Status bit requirements (4.3.3.5.3). An RT shall implement the status bits as follows:

 Message error bit (4.3.3.5.3.3) – Required
 
 Instrumentation bit (4.3.3.5.3.4) – Always logic zero
 
 Service request bit (4.3.3.5.3.5) – Optional
 
 Reserved statue bits (4.3.3.5.3.6) – Always logic zero
 
 Broadcast command received bit (4.3.3.5.3.7) – If the RT implements the broadcast option, then this bit shall be required.
 
 Busy bit (4.3.3.5.3.8) – As required by 30.5.3
 
 Subsystem flag bit (4.3.3.5.3.9) – If an associated subsystem has the capability for self test, then this bit shall be required.
 
 Dynamic bus control acceptance bit (4.3.3.5.3.10) – If the RT implements the dynamic bus control function, then this bit shall be required.

 Terminal flag bit (4.3.3.5.3.11) – If an RT has the capability for self test, then this bit shall be required.

*30.5.3 Busy bit (4.3.3.5.3.8). The existence of busy conditions is discouraged. However, any busy condition, in the RT or the subsystem interface that would affect communication over the bus shall be conveyed via the busy bit. Busy conditions, and thus the setting of the busy bit, shall occur only as a result of particular commands/messages sent to an RT. Thus for a non-failed RT, the bus controller can, with prior knowledge of the remote terminal characteristics, determine when the remote terminal can become busy and when it will not be busy. However, the RT may also set the busy bit (in addition to setting the terminal flag bit or subsystem flag bit) as a result of failure/fault conditions within the RT/subsystem.

*30.6 Broadcast (4.3.3.6.7). The only broadcast commands allowed to be transmitted on the data bus by the bus controller shall be the broadcast mode commands identified in table 1. The broadcast option may be implemented in remote terminals. However, if implemented, the RT shall be capable of distinguishing between a broadcast and a non-broadcast message to the same subaddress for non-mode command messages. The RT address of 11111 is still reserved for broadcast and shall not be used for any other purpose.

*30.7 Data wrap-around (4.3.3.5.1.4). Remote terminals shall provide a receive subaddress to which one to N data words of any bit pattern can be received. Remote terminals shall provide a transmit subaddress from which a minimum of N data words can be transmitted. N is equal to the maximum word count from the set of all messages defined for the RT. A valid receive message to the data wrap-around receive subaddress followed by a valid transmit command to the data wrap-around transmit subaddress, with the same word count and without any intervening valid commands to that RT, shall cause the RT to respond with each data word having the same bit pattern as the corresponding received data word. A data wrap-around receive and transmit subaddress of 30(11110) is desired.

*30.8 Message formats (4.3.3.6). Remote terminals shall, as a minimum,implement the following non-broadcast message formats as defined in 4.3.3.6: RT to BC transfers, BC to RT transfers, RT to RT transfers (receive and transmit), and mode command without data word transfers. For non-broadcast messages, the RT shall not distinguish between data received during a BC to RT transfer or data received during a RT to RT transfer (receive) to the same subaddress. The RT shall not distinguish between data to be transmitted during an RT to BC transfer or data to be transmitted during an RT to RT transfer(transmit) from the same subaddress. Bus controllers shall have the capability to issue all message formats defined in 4.3.3.6.

*30.9 RT to RT validation (4.3.3.9). For RT to RT transfers, in addition to the validation criteria specified in 4.4.3.6, if a valid receive command is received by the RT and the first data word is received after 57.0 plus or minus 3.0 microseconds, the RT shall consider the message invalid and respond as specified in 4.4.3.6. The time shall be measured from the mid-bit zero crossing of the parity bit of the receive command to the mid-sync zero crossing of the first expected data word at point A as shown on figures 9 and 10. lt is recommended that the receiving RT of an RT to RT transfer verify the proper occurrence of the transmit command word and status word as specified in 4.3.3.6.3.

*30.10 Electrical characteristics (4.5)

*30.10.1 Cable shielding (4.5.1.1). The cable shield shall provide a minimum of 90.0 percent coverage.

*30.10.2 Shielding (4.5.1). All cable to connector junctions, cable terminations, and bus-stub junctions shall have continuous 360 degree shielding which shall provide a minimum of 75.0 percent coverage.

*30.10.3 Connector polarity. For applications that use concentric connectors or inserts for each bus, the center pin of the connector or insert shall be used for the high (positive) Manchester bi-phase signal. The inner ring shall be used for the low (negative) Manchester bi-phase signal.

*30.10.4 Characteristic impedance (4.5.1.2). The actual (not nominal) characteristic impedance of the data bus cable shall be within the range of 70.0 ohms to 85.0 ohms at a sinusoidal frequency of 1.0 megahertz.

*30.10.5 Stub coupling (4.5.1.5). For Navy applications, each terminal shall have both transformer and direct coupled stub connections externally available. For Navy systems using these terminals, either transformer or direct coupled connections may be used. For Army and Air Force applications, each terminal shall have transformer coupled stub connections, but may also have direct coupled stub connections. For Army and Air Force systems, only transformer coupled stub connections shall be used. Unused terminal connections shall have a minimum of 75 percent shielding coverage.

*30.10.6 Power on/off noise. A terminal shall limit any spurious output during a power-up or power-down sequence. The maximum allowable output noise amplitude shall be ±250 mV peak, line-to-line for transformer coupled stubs and ±90 mV peak, line-to-line for direct coupled stubs, measured at point A of figure 12.

Supersedes pages dated 12 February 1980.

Scroll to top