Whereas both the electrical and link layer can be interchanged with other existing standards (such as Ethernet or X.25), for the specific purposes of the space bus those layers are as defined in this table.

*space bus* - the whole of electrical, link and logical layer as defined in this specification;

Electrical layer

For the purpose of the space bus, the electrical layer is as describe below.

Space is interpreted as logical 0, mark as logical 1.

Wiring & connectors

At the lowest level, SpaceBus consists of a length of standard Category 5 UTP cable. Connections on the bus are made with RJ45 (8P8C) connectors. The communications bus itself consists of an EIA-485 connection over one twisted pair of the cable (designated A and B as per the EIA-485 spec). Another twisted pair (A' and B') is used as return for [%TOPIC%#T_junctions|T_45junctions]. The remaining two pairs are used to provide +48VDC power in accordance with the [httphttp://lib.euroinfomedia.com/index.php?mact=DownCnt,m61d78,click,1&m61d78name=802.3at-2009&m61d78link=..%252Ffiles.euroinfomedia%252Fstandarts%252Fieee%252F802.3at-2009.pdf&m61d78returnid=88&page=88 IEEE 802.3at-2009 standard] for Power over Ethernet (pinout alternative B). This will minimise damage to computers should the cable be confused for one carrying Ethernet. The specific pinout is as follows:

Termination and bias

The bus is terminated at both ends with a resistor equivalent to the typical resistance of the cable (100ohm for UTP). In addition, a bias is applied to keep the idle level of the line as 'space' (logical low). Termination and bias-circuitry is combined with link-level arbitration of media access as described in [SpaceBusSpecification#Space_bus_flow_control_40sbfc_41|Space bus flow control (sbfc)].

T-junctions

To provide easily accessible bus devices in a room while keeping main wiring overhead and the bus linear (preventing stubs), one pair is designated as a return pair, making T-junctions with one cable possible. A simplified representation of the wiring can be found in figure 1.

Bus power

A single bus will be powered by a stand-alone power supply. The power adheres to the PoE standard (

Link layer

At the link-level, the space bus protocol (SBP) regulates access to the (shared) bus and specifies adressing of physical devices. Each unit of data transmission on the link level is a _frame_, which consists of a series of bytes. Bytes are sent as logical ones and zeroes as defined in the electrical layer, with the least significant bit first. A further division is made in bytes and words:

Addresses range from 0-255, with the special address 0 being reserved as the broadcast address.

Checksum

Some way of checking correct transmission.

Space bus flow control (sbfc)

The only frame-type reserved for the link layer is 0x00, which indicates a frame used in SBP flow control. The payload of a single sbfc frame has a length of one byte, and can contain the following values:

0x00 - RTS (Request To Send)

0x01 - CTS (Clear To Send)

0x02 - HELLO

0x03 - PR (Pulse Request)

0x04 - PAC (Primary Arbiter Pulse)

0x05 - SAC (Secondary Arbiter Pulse)

Access to the bus is arbitrated by a special device: the arbiter. To provide redundancy, two arbiters are placed at each end of the bus. A jumper on each arbiter configures one as the primary and the other as the secondary. The primary arbiter listens for RTS frames sent by the attached devices, queues CTS responses and monitors succesfull transmission. The arbiter (nor the entire SBP protocol) makes any guarantee about successful transmission and reception of a given communication. The secondary arbiter will stand by idle under normal circumstances. When it detects that the primary arbiter has gone off-line, it will take over. Arbiters have no bus address and communicate primarily with the broadcast address.

Insertion of a new device results in the following dialogue between the device (D1) and the active arbiter (A):

The CTS sequence will enable the device to synchronize with the bus. It knows the exact bitstream that comprises the CTS packet, and can thus scan the bus until it has matched the entire bit-stream. It can not do this relying solely on the sync pattern, as this may also be a valid part of the header or payload. Note that the particular bit-stream can still be part of a payload. *CONCERN*

Logical layer

The [httphttp://openctrl.org/ openctrl protocol], which is still under heavy development, forms the logical layer.

Application layer

The specification does not define the application layer.

Raised concerns

C1 - synchronisation

Relying on the synchronisation frame is not working, since the sync pattern may be a legit part of the payload.

Relying on the CTS packet sent in response to the initial RTS on device insertion is also not safe: the particular CTS packet could be a legit part of a payload.

Proposed solution: add a 9th bith that alternates between 1 and 0, this can help in synhronising up with the bitstream, and enables line-idle detection.