Onboard Data Handling and Telemetry: Lesson 5: Onboard Communications Links Introduction & Mil-Std-1553B

Onboard Data Handling and Telemetry
LESSON 5: ONBOARD COMMUNICATIONS LINKS INTRODUCTION & MIL-STD-1553B

OBDH ARCHITECTURE S/S Spacecraft Subsystems
TRANSPONDERS
TELEMETRY OBDH ARCHITECTURE
Data format and
ADC (Functional)
High / Low / Passive
(Functional)
Analog High Priority
S/S
control logic Telemetry
Serial Digital HOUSEKEEPING
PAYLOAD
DATA STORAGE S/S

GPS On-Board
Processing HOUSEKEEPING
receiver Time
RTU S/S
Digital Bus
Interface
S/S S/S
Ultra-stable
Oscilator
RM &
Discrete
FDIR S/S
I/O Interfaces
HOUSEKEEPING
TELLECOMMAND DECODER S/S

COMMAND PULSE
TRANSPONDERS
Serial Digital DECODING UNIT

COMMAND COMMAND
MESSAGE MESSAGE High Priority Commands
VALIDATION DECODING Power Control & S/S
(HPC)
Distribution Unit
High Priority Command (PCDU)
LESSON 5: ONBOARD COMMUNICATIONS LINKS INTRODUCTION
Overview OVERVIEW
As seen previously, the OBDHS includes a large variety of communication links

between the OBDH and other satellite subsystems and within the OBDHS itself.
The links between functional blocks represented in the functional architecture are
translated to many different physical implementations pending on the hardware
architecture selected for each satellite.
Overview OVERVIEW
We can differentiate three different concept approximations for on-board
communication links topologies:
• Centralized
• Bus
• Network
Selection of each topology is done in function of each mission specification,

as each approximation has advantages and disadvantages pending on final
application. Nevertheless nowadays, for large satellites, network or bus
configurations are the most used, and particularly the bus approximation due to its
scalability and reuse characteristics.
Overview OVERVIEW
Some terms definitions [RD20]:
Host System
A host system uses the services of the network or bus (read/write/others). It
consists in one or multiple application(s) (HW, SW or hybrid HW/SW) interfaced to
one or multiple end-points which are connected to the network routers/switches or
bus
End point
An end-point is the interface between a network / bus and the rest of the host
system providing a single port into the network or bus and providing services to a
host system.
Node
A node is understood as a component able to process a part or an entire packet.
Typically, it can be an end-point, a switch, a router or bridge.
Centralized Centralized
In a centralized topology one control unit is used as the “master” being the core of
the communication system.
Extracted from RD12

Centralized Centralized
This approximation may be the more direct and simple approximation for
small satellites with limited number of communication links, resulting in a low cost
implementation. For small satellites also this topology permits an easy test and
integration, allowing high rates of data transmission.
When the number of links increases in medium/large satellites this approximation

become complex and difficult to expand or reuse.
This topology allows the use of different types of interfaces between each
subsystem the central node communicates with. This is an advantage for small
satellites being a topology flexible for incorporate different hardware modules, but
really inefficient system when the number of different types of interfaces increases.
Bus BUS
As described in [RD20]: “A bus (or communication bus) is understood as
communication system made of one or several physical links to which end-points
with integrated switching functions are connected.”
Extracted from RD12

Bus BUS
The bus concept is scalable, modular and easy to integrate and test as it uses
the same standardized interface for all modules using the bus. Data transmitted
through the bus can be easily monitored w.r.t centralized topology.
When selecting a bus, the I/F with the different HW modules has to be implemented
following the bus standard, this implies that all modules has to communicate using
same bus what could be difficult when integrating modules from different
manufactures.
A faulty device may interfere or block bus communications with other modules in the
same bus, thus isolation techniques or redundancy shall be considered for avoiding
one faulty link in a bus could block the whole bus communications.
Network Network
The network topology is similar in reusability and scalability w.r.t the bus
concept.
The network concept permits to handle faulty devices in a more tolerant way than
the bus concept (but also special considerations has to be taken to avoid
communication blocking). Usually permits higher data transmission rates w.r.t bus
concept. Nevertheless it is more difficult to monitor the traffic in the network.
Network topology could result inefficient and complex for smaller satellites being
more orientated when the number of on-board links is elevated.
Network Network
Extracted from RD12

Latency & Bit numbering conversion Latency

The latency is basically the time between the transfer request being made by the
software and the transfer being completed on the data bus [RD12].
From ECSS standards:
The first bit in the field (starting from the left) is defined to be “Bit 0” MSB (Most
Significant Bit) and will be represented as the left most justified bit in a figure. The
next bit is called “Bit 1”, and so on, up to “Bit N-1” (LSB or Less Significant Bit), the
bits being represented in this order from left to right in a figure.
The MSB is transmitted first and LSB is last transmitted.
Onboard Data Handling and Telemetry
LESSON 5: MIL-STD-1553B
Overview OVERVIEW
MIL-STD-1553B has large historical of use in space, and nowadays is still one of
the buses more used spacecrafts.
We have seen this communication bus in previous examples in this course.
We will see the most relevant information for using this bus. The objective of this
lesson is not providing a complex class on MIL-STD-1553B bus, the objective is
providing a good introduction of the key elements of this bus, its capabilities and
main characteristics.
Overview OVERVIEW
Advantages Disadvantages
Single pair of cables-> simple Power consumption is very high during
data transmission.
Differential transformer coupling-> noise Harness related is volume and mass
reduction (single ended noise) demanding (isolating and coupling
transformers).
Using transformer coupled connexion it I/F circuitry complex and space
can be routed up to 30 meters demanding increasing PCB size.
As it has being used for so long, there are
several physical components available
space qualified. Also, data and
information is available.
Redundancy included in the protocol as
specified in ECSS standard
Overview OVERVIEW
Parameter Value
Data rate 1MHz
Word length 20 bits
Data bits/Word 16 bits
Message Length 32 data words max
Type of transmission Half-Duplex
Synchronization Asynchronous
Protocol Master/slave
Command/response
Number of remote terminal 31
maximum
Type of terminals Remote terminal; bus
controller and bus monitor
1553B Basics 1553B Basics

There are three types of communication devices in MIL-STD-1553B data bus system:
• 1 Bus Controller (BC). Responsible for managing all communications on the bus
(this role is usually accomplished by the OBC).
• Remote Terminals (RT). Up to 31 RT in a data bus system. A RT can be the
controller of a subsystem or a router connected to multiple subsystems.
• Bus Monitors (BM). Commonly used for integration and test for debugging
purposes.
MIL-STD-1553 bus architecture used in most spacecraft’s:
• OBC with platform subsystems
• OBC with payload
• Also it is possible to put together in the same bus platform and payload being the
OBC the BC.

RT may be intelligent units (Star tracker, GNSS receiver, payload interface unit)
or non-intelligent units:
• Non-intelligent units may use single message BC-RT and RT-BC transfers (using
basic MIL-STD-1553B messages) via dedicated sub-addresses.
• Intelligent units will communicate via a Data Block Transfer protocol
composed by one or several messages (as we will see later ECSS-E-ST-50-13C
standard permits so implement complex protocols over the basic 1553B
protocol); the Block transfer may transport any Data-Blocks including PUS-
Packets.

There are 3 word types:
• Commands
• Data
• Status
All of them have same structure but different format:
Each word is twenty bits in length (a word lasts 20µs, 1MHz frequency rate):
• 3 bits for synchronization and defining if it is or a data word or a
command/status word
16 bits with the information. Different for each word type
• 1 parity bit (odd parity)
Extracted from [RD56]

BC-> RT transfer
Immediately after the command word the BC transmits the data bits.
When all of the data words have been transmitted, the bus is left idle for some time
(12 µs) until the addressed RT responds with a status word that gives information
on whether the transfer was successful or not.
Master/slave command/response protocol:

Any message (data transfer or command) starts with the BC issuing a command
word:
• Includes the RT identification to which RT the message is issued (5 bit RT address
ﬁeld). Address 31 indicates a broadcast transfer, i.e. all RTs connected to the bus
may receive data. It is not possible to transmit data from the RTs using broadcast
addressing.
• The number of data words to be transferred (from 1 to 32),
• Definition if it is a BC -> RT transfer or a RT -> BC transfer.
RT-> BC transfer
- The BC transmit command and wait for addressed RT response
- RT responds with status word (OK, NOK) that gives information on whether the
transfer can be carried out or not
- After status words transmits the requested number of data words
In addition to the data transfers there are control commands, called mode
commands. These are recognized by the RT sub-address being 0 or 31 and they
may also result in a single data word being transmitted, either from the BC to the RT
or from the RT to the BC.


Physical Layer 1553B Basics

The MIL bus uses a pair of wires.
All devices (controller and remote terminals) use coupling transformers, which only
couples alternating currents (the desired signals) but does not pass through direct
current, so the bus cannot be shorted.
Signal level must be DC-balanced in order to avoid transformer saturation and

overshoot problems when the bus transfers are completed.
Physical Layer 1553B Basics

Differential signaling. Coupling transformers only couples alternating currents (info) but do not pass
direct current avoiding short-circuit.
Transformer coupling. Direct coupling.
Direct Coupling.
Bus: The cable between couplers.

Coupler: Transformer interconnect from the bus to
the stub of a BC, RT or Monitor. The transformer
ratios are a step down from the stub to the bus
with a ratio of 1.41
Stub: The cable between the transformer
and the BC, RT or Monitor.
1:1 transformer inside the BC, RT or

Monitor computer to isolate internal
shorts to the bus
0,3 m max length

30 m max length
Transformer coupled stubs are preferred for their fault tolerance and
better matching to the impedance of the bus, and consequent
Extracted from [RD57] reduction in reflections, etc.
Physical Layer HARDWARE

Most significant bit transmitted first.
The signal modulation used is called Manchester coding or split phase level (SPL) coding
and is a special case of binary phase shift keying (BPSK) with one subcarrier period per
data bit.
When the bus is idle (no transmission), the bus signal

should be at ground


This type of coding works on the basis of zero-crossing detection (i.e., the information is
contained in the directions of zero crossings that occur at 1 -us intervals, giving a 1 -MHz bit
rate).
The sync is made up of two 1.5-us periods (one-and-a-half bit times), one high and the
other low (pending if it is a Status/Command word or a Data word).
The 1553B waveforms are asynchronous; that is to say, the terminals in the system have
their own clocks and are not synchronized with the bus waveforms at the beginning of a
message. To correctly decode data, a terminal must derive the clocking of the received
signal. The term sync is used for this purpose. The sync crossing provides the reference
from which a receiver-decoder determines the time when the midbit zero crossings of the
word will take place. The first midbit zero crossing happens 2.0 us after the sync crossing;
subsequent midbit zero crossings occur at intervals of 1.0 us thereafter until the end of the
word.



LESSON 6: MIL-STD-1553B Current mode

typically differential TTL
Voltage mode

1553B Redundancy 1553B Basics
As defined in RD-21, each 1553 bus is internally redundant (channels A and B). The
OBC is bus controller (BC) on each 1553 bus.
Each remote terminal (RT) is connected to both channels of its MIL-STD-1553 bus
and is identified with a unique RT address for the bus.
The purpose of electrical termination is to

minimize the effects of signal reflections that
can cause waveform distortion
Fully coss-strapped example

Simple coss-strapping example

Nominal and Redundant units

shall have different RT
addresses

1553B in detail
MIL-STD-1553B standards allows messages of up to 64 bytes transmission.

Also it provides basic way to interface with RT.
From this basic standard, developers can define a more complex system for
transmitting larger data structures (as CCSDS packages or files) or implement
RT management…
But again, in space, reuse of things will increase efficiency and reliability
(between other benefits as reusability)
That is why ESA has standardized 1553B usage including upper OSI
(Open System Interconnection) layers.
1553B in detail
1553B standard is focused in defining the lowest OSI layers. Above data link
layer ECSS-E-ST-50-13C standard [RD-55] specifies how to implement on
top of the basic 1553 message the network layer allowing to implement more
complex protocols for transmitting complex data structures (Data Block
Transfer ) as the ones defined by the CCSDS for the space packets or PUS
packages.
ECSS-E-ST-50-13C is widely used in European space missions.
Protocols services defined in ECSS-E-ST-50-13C:
• Time synchronization
• Time distribution
• Communication synchronization
• Data block transfer
• Terminal management.
1553B in detail
MIL-STD-1553B and additional standards (ECSS) permits to implement over this bus the
following ISO layers:
• Physical Layer: as shown previously including harness (cables, connectors,
transformer-coupled connections…)
• Data Link Layer: as shown previously for 1553B basics: word control, message
transfer control, multiple message control, error notification…
• Network Layer: initialization, (re)configuration, error notification, RT address allocation,
redundancy management.
• Transport Layer: implementation of 1553B minor and major acquisition/distribution
frames, synchronization, flow control, error management.
• Session Layer: handling of periodic and aperiodic messages, large data transfer
protocol, communication slots handling, error and fault management.
Let´s see key points of some of these layers using 1553B

1553B in detail – Data link layer
Some Data Link Layer requirements applicable to the OBC and all units
connected 1553 busses following ESA standards:
• As much as possible, the number of words shall be constant for a given sub-
address.
• The BC NO RESPONSE time out shall be 14 microseconds.
• Mode Codes applicable (an example in following slides) and their detailed
description.
• The use of the Status Word bits (example in following slides) and their detailed
description.
• Define what is a valid message,
• Define what is an illegal message and what shall be the RT behaviour,
• Define the BC error handling upon a time out, due to a late or no response from
RT.
Status word bits applicability example from SAVOIR Data Handling Handbook
1553B in detail – Transportation link layer
The Transportation Layer will have two implementations to respect the

specific needs of intelligent and non-intelligent RT’s.
Intelligent units will communicate via a Block Transfer protocol (sub-

addresses 11 to 28), whereas non-intelligent units may use standard BC-RT
and RT-BC transfers via dedicated sub-addresses.
Sub-Address Usage for

intelligent units

Sub-Address Usage for non- intelligent units

Mode Codes example from

SAVOIR data SAVOIR Data
Handling Handbook

For spacecraft control, the data bus usage needs to be deterministic at any time
supporting synchronous and asynchronous data transfers. The Mil-Bus scheduler
shall implement major and minor frames synchronized to the on-board time. Major
frames shall have a period of 1 second, divided into 8 to 16 minor frames, pending
on user requirements. This operation, known as bus profiling, is often performed
during the definition of the spacecraft-level system specifications and foresees the
allocation of dedicated bandwidth for each activity on the data bus
Following slides show examples for different Major and Minor Slot timing for 8
minor frames. Each minor frame shall provide a polling list of Mil-Bus messages.
The polling list shall allow specification of delays between the different messages to
support the implementation of low level protocols with non-intelligent remote
terminals.
As explained in RD-12: “the 1553 data bus is a serial communications

bus with a rather low speed. A full size message carrying 64 bytes
occupies the bus for about 700 ls and it cannot be interrupted. Thus, it
is not possible for software to perform urgent random data accesses
over the bus in order to access sensors and actuators. Instead, the bus
trafﬁc must be scheduled to meet the performance requirements in
terms of bandwidth and latency. The latency is basically the time
between the transfer request being made by the software and the
transfer being completed on the data bus”


1553B in detail – Session layer

1553B in detail – Services
Services provided by ECSS-E-ST-50-13C:

• Time service which supports the distribution of time information across a 1553
data bus.
• Communication Synchronization service which supports time multiplexing of
data bus messages in a deterministic way.
• Set Data and Get Data services which support non-confirmed data transfers of
restricted length with a simple protocol without handshake.
• Data Block Transfer service which supports confirmed transfers of data blocks
on request of the sender with handshaking supported by a protocol.
• Terminal Management services which provide standard functions and
structured data in support to the implementation of project specific terminal
management.
OBDH Introduction – Biography
• [RD1] G. Maral, M. Bousquet and Z. Sun Satellite Communications Systems: Systems, Techniques and Technology,
Wiley, 2009
• [RD2] M. Macdonald and V. Badescu The International Handbook of Space Technology, Springer, 2014
• [RD3] P. Fortescue, G. Swinerd and J. Stark (Editors) Spacecraft Systems Engineering, 4th Edition, John Wiley, 2012
• [RD4] J.Bouwmeester Lecture Notes - Spacecraft Technology (AE3534), TuDelf, 2018.
• [RD5] E. Keesee Satellite Telemetry, Tracking and Control Subsystems, Massachusetts Institute of Technology, 2003
• [RD6] Architectures of Onboard Data Systems:
https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Onboard_Computer_and_Data_Handling/Architect
ures_of_Onboard_Data_Systems
• [RD7] ECSS, ECSS-S-ST-00-01C – Glossary of terms (1 October 2012)
• [RD8] P. Armbruster Space Avionics Open Interface Avionics Architecture SAVOIR Overview, ESA, 2011
• [RD9] LARSON, Wiley J.; WERTZ, James Richard. Space mission analysis and design. Torrance, CA (United States);
Microcosm, Inc., 1999.
• [RD10] What is On-board Data Processing?:
http://www.esa.int/Enabling_Support/Space_Engineering_Technology/Onboard_Data_Processing/What_is_On-
board_Data_Processing
• [RD11] M. RIMPAULT, Multi-mission On-board High Performance Payload Data Processing Platform, ESTEC – Workshop
OBDP2019 Noordwijk, 25th of February 2019
• [RD12] HULT, Torbjörn; PARKES, Steve. On-Board Data Systems. The International Handbook of Space Technology. Springer,
Berlin, Heidelberg, 2014. p. 441-470.
• [RD13] “New Space and Old Space”. https://wanderingalpha.com/new-space-vs-old-space
• [RD14] A. de Concini, J. Toth The future of the European space sector How to leverage Europe’s technological leadership and
boost investments for space ventures. European Commission, 2019
• [RD15] SAVOIR. SAVOIR Generic OBC Functional Specification. European Space Research and Technology Centre, 2019.
• [RD16] SAVOIR. SAVOIR Flight Computer Initialisation Sequence Generic Specification. European Space Research and
Technology Centre, 2016
• [RD17] SAVOIR. SAVOIR RTU Functional and Operability Requirements. European Space Research and Technology Centre,
2018
• [RD18] SAVOIR. SAVOIR Data Storage System Requirement Document. European Space Research and Technology Centre,
2017
• [RD19] Generic OIRD Working Group. Generic Operations Interface Requirements Document (GOIRD). European Space
Operations Centre, 2019
• [RD20] SAVOIR. SAVOIR On-board Communication System Requirement Document. European Space Research and
Technology Centre, 2019
• [RD21] SAVOIR. SAVOIR Data Handling Handbook. European Space Research and Technology Centre, 2019
• [RD22] SAVOIR. SAVOIR FDIR Handbook. European Space Research and Technology Centre, 2019
• [RD23] SAVOIR. SAVOIR Functional Reference Architecture. European Space Research and Technology Centre, 2019
• [RD24] CCSDS 130.0-G-2: Overview of Space Communications Protocols. Green Book. Issue 2. December 2007. Available at
www.ccsds.org.
• [RD25] CCSDS 200.0-G-6: Telecommand Summary of Concept and Rationale. Green Book. Issue 6. January 1987.
• [RD26] CCSDS 727.0-B-4: CCSDS File Delivery Protocol (CFDP). Blue Book. Issue 4. January 2007
• [RD27] CCSDS 231.0-B-2: Telecommand Synchronization and Channel Coding. Blue Book. Issue 2. September 2010
• [RD28] CCSDS 232.0-B-2: Telecommand Space Data Link Protocol. Blue Book. Issue 2. September 2010
• [RD29] CCSDS 232.1-B-2: Communications Operation Procedure-1. Blue Book. Issue 2. September 2010
• [RD30] CCSDS 133.1-B-2: Encapsulation Service. Blue Book. Issue 2. October 2009
• [RD31] CCSDS 133.0-B-1: Space Packet Protocol. Blue Book. Issue 1. September 2003
• [RD32] CCSDS 301.0-B-4: Time Code Formats. Blue Book. Issue 4. November 2010
• [RD33] CCSDS 727.0-B-4: CCSDS File Delivery Protocol (CFDP). Blue Book. Issue 4. January 2007
• [RD34] CCSDS 132.0-B-1: Telemetry Space Data Link Protocol. Blue Book. Issue 1. September 2003
• [RD35] CCSDS 100.0-G-1: Telemetry Summary of Concept and Rationale. Green Book. Issue 1. December 1987
• [RD36] CCSDS 131.0-B-1: Telemetry Synchronization and Channel Coding. Blue Book. Issue 1. September 2003
• [RD37] CCSDS 130.2-G-3. Space Data Link Protocols—Summary of Concept and Rationale. 2012.
• [RD38] Jalilian, S., SalarKaleji, F., & Kazimov, T. Fault Detection, Isolation and Recovery (FDIR) in Satellite Onboard
Software,2017,
• [RD39] J. Day, M.Ingham. Fault Management at JPL: Past, Jet Propulsion Laboratory, California Institute of Technology,
ADCSS 2011
• [RD40] SalarKaleji, Fatemeh, and Aboulfazl Dayyani. "A survey on Fault Detection, Isolation and Recovery (FDIR) module in
satellite onboard software." 2013 6th International Conference on Recent Advances in Space Technologies (RAST). IEEE,
2013.
• [RD41] WANDER, Alexandra; FÖRSTNER, Roger. Innovative fault detection, isolation and recovery strategies on-board
spacecraft: state of the art and research challenges. Deutsche Gesellschaft für Luft-und Raumfahrt-Lilienthal-Oberth eV, 2013.
• [RD42] Guide, Partial Reconfiguration User. "UG702 (v14. 1)." Xilinx Inc., Apr 24 (2012).
• [RD43] Eickhoff, Jens. Onboard computers, onboard software and satellite operations: an introduction. Springer Science &
Business Media, 2011.
• [RD44] CCSDS 232.0-B-3 2015. TC SPACE DATA LINK PROTOCOL.
• [RD45] ECSS. ECSS-M-30-01A. Organization and conduct of reviews. 1999
• [RD46] ECSS. ECSS-Q-ST-30C-Rev.1. Dependability.2017

• [RD47] ECSS. ECSS-Q-ST-30-11C Rev.1 – Derating – EEE components, 2011
• [RD48] ECSS. ECSS-Q-ST-30-02C – Failure modes, effects (and criticality) analysis (FMEA/FMECA), 2009
• [RD49] Web resource: https://www.isispace.nl/products/command-data-handling-systems/
• [RD50] Web resource: https://sentinel.esa.int/web/sentinel/missions/sentinel-5/instrument-payload
• [RD51] P. Snoeij et al. Sentinel-1 Instrument Overview. SEASAR 2012 ESA, June 2012.
• [RD52] Web resource: https://www.esa.int/About_Us/Business_with_ESA/How_to_do/
ESA_s_Invitation_to_Tender_System_EMITS
• [RD53] Condor Engineering, Inc. MIL-STD-1553 Tutorial (1600100-0028), Issue 3.41, June 5, 2000
• [RD54] G. Maral, M. Bousquet and Z. Sun Satellite Communications Systems: Systems, Techniques and Technology, Wiley,
2009
• [RD55] ECSS-E-ST-50-13C: Interface and communication protocol for MIL-STD-1553B data bus onboard spacecraft,
November 2008
• [RD56] MIL-STD-1553B Military Standard. Department of Defence USA. Sep. 1978
• [RD57] MIL-STD-1553C Military Standard. Department of Defence USA. Feb. 2018
• [RD58] S.Corrigan. TI Application Report SLOA101B - Introduction to the Controller Area Network (CAN), Texas Instruments,
May 2016
• [RD59] ECSS. ECSS-E-ST-50-15C. CANbus extension protocol. ESA, May 2015

• [RD60] Texas Instruments. Product Datasheet SNOSAN0B - DS16F95QML EIA-485/EIA-422A Differential Bus Transceiver,
Texas Instruments, Sep 2005.
• [RD61] S.Corrigan. TI Application Report SLLA270 - Controller Area Network Physical Layer Requirements, Texas Instruments,
Jan 2008
• [RD62] ECSS. ECSS-E-ST-50-12C. SpaceWire - Links, nodes, routers and networks. ESA. May 2019
• [RD63] MIL-HDBK-1553A Military Standard. Department of Defence USA. Nov. 1988.

Onboard Data Handling and Telemetry: Lesson 5: Onboard Communications Links Introduction & Mil-Std-1553B

Uploaded by

Copyright:

Available Formats

You might also like

Onboard Data Handling and Telemetry: Lesson 5: Onboard Communications Links Introduction & Mil-Std-1553B

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Onboard Data Handling and Telemetry: Lesson 5: Onboard Communications Links Introduction & Mil-Std-1553B

Uploaded by

Copyright:

Available Formats

Onboard Data Handling and Telemetry

LESSON 5: ONBOARD COMMUNICATIONS LINKS INTRODUCTION & MIL-STD-1553B

DATA STORAGE S/S

TELLECOMMAND DECODER S/S

Serial Digital DECODING UNIT

As seen previously, the OBDHS includes a large variety of communication links

Selection of each topology is done in function of each mission specification,

Extracted from RD12

When the number of links increases in medium/large satellites this approximation

Extracted from RD12

Extracted from RD12

Latency & Bit numbering conversion Latency

We have seen this communication bus in previous examples in this course.

1553B Basics 1553B Basics

1553B Basics 1553B Basics

1553B Basics 1553B Basics

1553B Basics 1553B Basics

Extracted from [RD56]

1553B Basics 1553B Basics

1553B Basics 1553B Basics

Master/slave command/response protocol:

1553B Basics 1553B Basics

1553B Basics 1553B Basics

1553B Basics 1553B Basics

Extracted from [RD56]

1553B Basics 1553B Basics

Extracted from [RD56]

Physical Layer 1553B Basics

Signal level must be DC-balanced in order to avoid transformer saturation and

Physical Layer 1553B Basics

Bus: The cable between couplers.

1:1 transformer inside the BC, RT or

0,3 m max length

Physical Layer HARDWARE

When the bus is idle (no transmission), the bus signal

Extracted from [RD56]

Physical Layer HARDWARE

Extracted from [RD63]

Physical Layer HARDWARE

Extracted from [RD63]

Physical Layer HARDWARE

Extracted from [RD63]

Physical Layer HARDWARE

Extracted from [RD63]

1553B Redundancy 1553B Basics

1553B Redundancy 1553B Basics

The purpose of electrical termination is to

Fully coss-strapped example

1553B Redundancy 1553B Basics

Simple coss-strapping example

Extracted from [RD21]

1553B Redundancy 1553B Basics

Nominal and Redundant units

Extracted from [RD21]

MIL-STD-1553B standards allows messages of up to 64 bytes transmission.

Let´s see key points of some of these layers using 1553B

1553B in detail – Data link layer