SSN Protokoll
aus MariaTheresia, der freien Wissensdatenbank
Author: Roland Stelzer (mailto:admin@roland-stelzer.info) InnoC.at (http://www.InnoC.at)
SSN ... Simple Sensor Network.
| Inhaltsverzeichnis |
Download Protocol Description
| Ssn_paper.pdf (50kB) [info] Simple Communication Protocol for Rapid Robot Prototyping |
R. Stelzer and K. Jafarmadar (2007): Simple Communication Protocol for Rapid Robot Prototyping. In proceedings of Humanoid and Service Robotics, Kosice, Slovakia.
Introduction
Every Sensor/Actuator speaks the same "language". A few functions (getdata, setdata, …) can be used to retrieve values from a lot of different sensors respectively set values of actuators. The developer of applications needs not to care about specific characteristics of the sensor/actuator hardware. The protocol is based on standardised serial communication (RS232). Therefore the devices can be connected to a lot of different systems (PC, PDA, microcontrollers, …) and all popular programming languages can be used.
As an example, it is possible to replace an infrared distance sensor with an ultrasonic one. Nothing needs to be changed in the control software, because both sensors modules understand the same getdata command and both deliver data (distance in this case) in the same predefined format. We use PIC microcontrollers to "translate" between the hardware specific signals and the SSN protocol.
Hardware Topology
A sensor or actuator device (SSN module) can directly be connected to the master’s serial interface. In this case the number of SSN modules is limited to the number of serial interfaces of the master. If a PC is used as master system, usually not more than one or two serial interfaces are available.
To connect more SSN modules a kind of serial multiplexer, the SSN switch, can be put in between the master and the SSN modules (see figure below). Up to 15 SSN modules can be connected to a single SSN switch. The SSN switch itself is connected to the master and listens for a request packet coming from the master. The SSN packet includes an address, which specifies the port of the SSN switch to which the desired SSN Module is connected.
/ -> Device 0x0
Master <--> SSN Switch <-- ...
\ -> Device 0xE
SSN switches can be cascaded, so that an infinite number of modules can be integrated in the network.
Process Flow when a Request Occurs
- SSN switch receives request packet from master
- SSN switch extracts the address part of the packet
- SSN switch forwards the complete packet to the switch-port corresponding to the address extracted before (Exception: Address 0xF is used for SSN switch cascading, see "Cascading" below).
- SSN switch waits for a reply packet from the SSN module and routes it back to the master. If no reply occurs within a certain time (100 ms), a timeout message will be sent to the master by the SSN switch.
The device (sensor/actuator) hast to wait at least 1 ms before it replies. Otherwise, the current implementation on the SSN switch cannot handle the reply.
Request Packet
The first byte of the request packet contains the header informations address and command. The address is coded in the most-significant halfbyte:
- Maximum of 15 SSN-Modules (0x0 to 0xE)
- If 0xF, see "Cascading"
The least-significant halfbyte contains the command:
- Get general information about a particular SSN module
0x0 … getinfo short (Details below) 0x1 … getinfo long
- Get value of a sensor device respectively status of an actuator:
0x2 … getdata string (\0-terminated) 0x3 … getdata byte 0x4 … getdata 2 bytes 0x5 … getdata 4 bytes
- Set value of an actuator device respectively change settings of a sensor:
0x6 … setdata string (\0-terminated) 0x7 … setdata byte 0x8 … setdata 2 bytes 0x9 … setdata 4 bytes (can be used for float values for instance)
- Reserved for the future:
0xA … <not defined yet> 0xB … <not defined yet> 0xC … <not defined yet> 0xD … <not defined yet> 0xE … <not defined yet>
- In case of error:
0xF … indicates an error, e.g. timeout (only for reply packets)
The commands getinfo short and getinfo long are supported by every SSN module. Which getdata and setdata commands are supported, differs from module to module. The reply packet on a getinfo short request gives information about the supported commands (see "Reply Packet to getinfo short").
Argument: Optional n Bytes of Data
- setdata n byte(s) requires an argument with n bytes length
- setdata string requires a \0-terminated string as argument
All the other requests do not have extra arguments.
Reply Packet for getinfo short
1st Byte:
As with all replies, the 1st byte is the unmodified request header.
2nd Byte:
Bit 0 - event bit: Is set to 0 after a getdata command.
If the sensor value changes, the bit
is set to 1. This needs not to be
implemented for each SSN module.
Bit 1 - not in use yet. This bit is set to 0
Bits 2 to 7 - Module type code
3rd Byte:
Gives information about the supported getdata and setdata commands. If
the corresponding bit is set to 1, the command is supported, otherwise
it is not.
Bit 0 - getdata string (\0-terminated)
Bit 1 - getdata 1 byte
Bit 2 - getdata 2 bytes
Bit 3 - getdata 4 bytes
Bit 4 - setdata string (\0-terminated)
Bit 5 - setdata 1 byte
Bit 6 - setdata 2 bytes
Bit 7 - setdata 4 bytes (eg. for float values)
Reply Packet
The first byte of the reply packet is basically identic to the first byte of the preceding request. Thus the most-significant halfbyte contains the adress (port number where the module is connected to the SSN switch) and the least-significant halfbyte describes the command. By means of the command, the SSN switch determines the number of bytes following the header byte.
An exception occurs in case of timeout. In this case the least-significant byte is 0xF. The length of the reply packet follows from the command (1 header byte + …):
- setdata produces no reply packet, not even a header byte.
- getinfo short, getinfo long and getdata string produce a \0-terminated string.
- getdata n bytes produces n bytes reply data.
- In case of timeout only the header with 0xF als least-significant halfbyte is replied.
Cascading
In principle the header within a request packet is one byte long (4 bits for the address and 4 bits for the command). If multiple SSN switches are cascaded, one byte is added in the front for each additional SSN switch. The most-significant halfbyte of this header contains 0xF. This indicates, that it is a cascade-header and the direct recipient of the packet is not an SSN module, but an additional SSN switch. The least-significant byte of the cascading header describes the port number to which the additional SSN switch is connected. The first byte (cascade-header) will be cut off by the first SSN switch and discarded. The rest of the packet will be forwarded to the next SSN switch. With this strategy, any number of SSN switches can be cascaded. It is just needed to add one byte cascade-header (0xF and port number) per level.
With this strategy, any number of SSN switches can be cascaded. It is just needed to add one byte cascade-header (0xF and port number) per level.
Example
SSN-S1
I---I-0--
Master I I-1-- SSN-S2
I----I I I-2------I---I-0-- SSN-S3
I PC I----I I-3-- I I-1-- I---I
I----I ... ... I I I--------I
I I-C-- I I-5-----I I-3----I MODULE I
I---I-E-- ... ... I--------I
I---I-E-- I I
I---I
Figure 1: Cascading via any Port
The following packet goes from the master to the first SSN switch …
1st byte - 0xF2 // cascade via port 2 to SSN switch 2 2nd byte - 0xF5 // cascade via port 5 to SSN switch 3 3rd byte - 0x30 // SSN module is attaced to port 3, getinfo short
… and from the first SSN switch to the second SSN switch …
1st byte - 0xF5 // cascade via port 5 to SSN switch 3 2nd byte - 0x30 // SSN module is attaced to port 3, getinfo short
… and from the second SSN switch to the third SSN switch (where the module is physically attached to) …
1st byte - 0x30 // SSN module is attaced to port 3, getinfo short
The SSN module receives the same packet format as it would be directly connected to the first SSN switch. Cascading has no influence on the reply packet, which gets simply forwarded along the hierarchy up to the master.
The SSN switch usually provides a standard cascading port. This is mounted in a way that another SSN switch can be attached to it directly (D-SUB, 9pol, male). This port can only be used for cascading, because of its port number 0xF. Cascading via this port works as follows:
0xFF // the first F indicates to be cascaded
// the second F describes the port via wich to be cascaded
// -> standard cascading port 0xF
The following example shows how to send a command to Device C via two SSN switches:
I----I I-------------I I-------------I
I PC I---I SSN-S1 I-F-I SSN-S2 I
I----I I-------------I I-------------I
I I I
3 8 4
I I I
I---I I---I I---I
I A I I B I I C I
I---I I---I I---I
Figure 2: Cascading via standard cascading port 0xF
0xFF // cascade via port 0xF to SSN switch 2 0x40 // send to device attached to port 4; command 0 = getinfo short
Remarks (to be translated)
Bei Tests der SSN-Hardware ist folgendes Problem aufgetreten, was eine geringfügige Adaptierung des Protokolls notwendig macht:
1) Clients antworteten bisher zu schnell für den Hub (verpasste erstes byte) Alle clients haben daher nach dem command/selector byte min. 1 ms zu warten bevor sie antworten, allerhöchstens aber 100ms -> sonst timeout
2) Das Timeout bezieht sich nur auf die beantwortung des command/selector bytes. wenn das device später abstürzt, hängt auch der hub - soll man einen master timeout implementieren? ein reset-pin zwischen controller-cpu und hub ? Wenn es ein Master-timeout gibt, wie signalisiert der Hub dem controller, daß so eines stattgefunden hat ?
3) Empfangspins am Hub sollten einen 100k widerstand gegen masse haben, damit das nicht-vorhandensein von clients zuverlässig erkannt werden kann.
FAQ (to be translated & answered)
- Warum wurde für die Kommunikation über RS232 kein Parity-Bit verwendet?
Es wurde versucht, das Protokoll so einfach wie möglich zu gestalten. Es wurde daher auch auf Error-Recovery-Mechanismen verzichtet. Einfach nur das Parity-Bit zu aktivieren (ohne zusätzliche Error-Recovery) hätte den Effekt, dass fehlerhafte Bytes zwar erkannt und ignoriert - aber nicht korrigiert - werden.
- Warum wurde RS232 und nicht RS485 verwendet um eine Bustopologie ohne Switch zu realisieren?
Aufgrund der Tatsache, dass (fast) jeder PC über eine RS232-Schnittstelle verfügt und die Implementierung verhältnismäßig einfach ist, haben wir und dafür entschieden.
- Ist auch drahtlose Kommunikation im SSN vorgesehen?
Die derteitige Implementierung ist kabelgebunden. Wir möchten aber in nächster Zeit verschiedene drahtlose Möglichkeiten (Infrarot RC5, Funk, ...) für die Kommunikation zwischen SSN-Switch und Master testen.
- Bei senddata/getdate 2/4 bytes: little-endian oder big-endian? Was ist Standard in C/Java?
- Pegelwandler (MAX232) bzw. Invertierung am Standard-Kaskadierport des SSN switch notwendig?
- Kommunikation zw. Modul und Switch mit TTL-Pegel invertiert oder nicht?
- Welcher Lizenz unterliegt die SSN Software?
- Warum wird keine asynchrone Kommunikation verwendet?
- Wie grenzt sich SSN von anderen Protokollen wie etwa I2C, CAN, 1Wire, Ethernet ab?
- Welche Timeout-Mechanismen sind derzeit implementiert, und zwar auf ...
- Master
- Device
- Switch
- Welche Fehlerkorrekturen gibt es? Was passiert, wenn ein Paket gar nicht, nicht vollständig oder fehlerhaft übertragen wird (device <-> switch bzw. switch <-> master)?
Comments
Please add your comments, remarks & questions here or send a mail to contact@innoc.at
