- 1 Overview
- 2 Definitions, terminology and notational conventions
- 3 Electrical layer
- 4 Link layer
- 5 Logical layer
- 6 Application layer
- 7 Raised concerns
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:
|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
- 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;
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:
|Pin no.||Pair no.||Colour||Name||Description|
|4||1||blue||DC+||Positive power. Can be lower than 48V due to cable loss -- In accordance with PoE spec.|
|7||4||white-brown||COM||Both power return and EIA-485 reference.|
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)].
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" />
A single bus will be powered by a stand-alone power supply. The power adheres to the PoE standard (
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:
- *byte* - 8 bits
- *word* - 16 bits, little endian (least significant byte first, most significant byte last)
A frame of n bits is formatted as:
The header is further specified as:
|sync||type||len LSB||len MSB||dst||src|
|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.
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 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):
| 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*
The OpenCTRL protocol, though still under development, forms the logical layer.
This specification does not define the application layer.
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.