SpaceBusSpecification

• CONCEPT*

Overview

This specification describes the SpaceBus hackerspace bus network. Its objective is to provide a robust network for simple devices to communicate over.

A layered approach is followed in the design of the protocol. The table below illustrates the layers:

Overview of protocol layers

Layer	Standard	Alternative standards	Domain	Examples
Application			uC	user input and sensor events, domotic control
Logical	openctrl	uberbus, X10, ...		events, control channels
Link	SBP	ethernet (link part), udp, ...		arbiters, bus devices
Electrical	EIA-485	ethernet (physical part), RS-232, radio FM, ...	wiring, transceivers	UTP, rj-45, T-junctions

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.

Definitions, terminology and notational conventions

• Numbers:
  • 0xNN - a hexadecimal number, digits in decreasing order of significance (example: 0x4A, 0xb6, 0x88);
  • bNNNNNNNN - a binary number, digits in decreasing order of significance (example b00101010, b11111111);
  • NN - a decimal number, digits in decreasing order of significance (example 66, 2011, 65535);
  • 0NN - an octal number, digits in decreasing order of significance (example 044, 071).
• *arbiter* - device combining bus termination, bias circuitry and media access arbitration;
• *bus address* - link layer device address, only valid on a particular bus;
• *SBP* - space bus protocol, the link-level protocol defined in this specification;
• *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 T-junctions. The remaining two pairs are used to provide +48VDC power in accordance with the 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:

Pinout of the 8P8C connector for SpaceBus

Pin no.	Pair no.	Colour	Name	Description
1	3	white-orange	A'	In T-junction: EIA-485 II. In regular wiring: unused
2	3	orange	B'
3	2	white-green	A	EIA-485 I
4	1	blue	DC+	Positive power. Can be lower than 48V due to cable loss -- In accordance with PoE spec.
5	1	white-blue	DC+
6	2	green	B	EIA-485 I
7	4	white-brown	COM	Both power return and EIA-485 reference.
8	4	brown	COM

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.

<img alt="splitter-wiring.png" height="238" src="%ATTACHURL%/splitter-wiring.png" title="splitter-wiring.png" width="400" />

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

• *byte* - 8 bits
• *word* - 16 bits, little endian (least significant byte first, most significant byte last)

A frame of n bits is formatted as:

Overall frame lay-out.

0-47	48-(n-8)	(n-8)-(n-1)
header	payload	checksum

Header

The header is further specified as:

SBLP header lay-out.

0-7	8-15	16-23	24-31	32-39	40-47
sync	type	len LSB	len MSB	dst	src

An explanation of terminology used.

shorthand	type	definition
sync	byte	hex number 0xFF
type	byte	0x00 - SBP flow control (sbfc)
byte		0x01 - openctrl
length	word	frame-length expressed in bytes, including header and checksum, len(payload)+7
dst	byte	destination bus address
src	byte	source bus address

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

Checksum

Some way of checking correct transmission. CRC?

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

| D1(1)->B(0) | RTS | | ... | optionally, other bus traffic occurs as decided by the arbiter | | A(0)->D1(1) | CTS | | D1(1)->B(0) | HELLO |

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 OpenCTRL protocol, though still under development, forms the logical layer.

Application layer

This 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 bit that alternates between 1 and 0, this can help in synchronising up with the bitstream, and enables line-idle detection.