Simple Sensor Interface protocol
From Wikipedia, the free encyclopedia
SSI (Simple Sensor Interface) protocol is a simple communications protocol designed for data transfer between computers or user terminals and smart sensors. SSI protocol is an Application layer protocol as in OSI model.
SSI protocol has been developed jointly by Nokia, Vaisala, Suunto, Ionific, Mermit and University of Oulu. Currently SSI is being developed within Mimosa project which is a part of European Union Framework Programmes on Research.
SSI protocol is used in point-to-point communications over UART and networking nanoIP applications. SSI also provides polling sensors and streaming sensor data. For RFID sensor tags SSI specifies memory map for sensor data.
The criterion for SSI protocol development are:
- general purpose
- simple – minimal overhead
- small footprint on the server (sensor) side
Sample implementation of SSI protocol for MSP430 microcontrollers will be published as open source during August 2006 by Nokia.
Contents |
[edit] SSI message structure
An SSI message is formed of a 2-byte header and n-byte payload. The header consists of one byte address (wildcard is '?', 0x3F in ASCII) and one byte message/command type. The different possible values for message/command type are presented in SSI v1.2 command base.
[edit] SSI v1.2 command base
| Command byte | Direction | Description |
|---|---|---|
| Q,q (0x51,0x71) | C-> | Query |
| A,a (0x41,0x61) | <-S | Query reply |
| C,c (0x43,0x63) | C-> | Discover sensors |
| N,n (0x4E,0x6E) | <-S | Discovery reply |
| Z,z (0x5A,0x7A) | C-> | Reset sensor device |
| G,g (0x47,0x67) | C-> | Get configuration data for a sensor. |
| X,x (0x58,0x78) | <-S | Configuration data response |
| S,s (0x53,0x73) | C-> | Set configuration data for a sensor |
| R,r (0x52,0x72) | C-> | Request sensor data |
| V,v (0x56,0x76) | <-S | Sensor data response |
| D,d (0x44,0x64) | <-S | Sensor response with one byte status field |
| M,m (0x4D, 0x6D) | <-S | Sensor response with many data points |
| O,o (0x4F,0x6F) | C-> | Create sensor observer |
| Y,y (0x59,0x79) | <-S | Observer created |
| K,k (0x4B,0x6B) | <-> | Delete sensor observer / listener |
| U,u (0x55,0x75) | <-> | Observer / listener finished |
| L,l (0x4C,0x6C) | <-S | Request sensor listener |
| J,j (0x4A,0x6A) | C-> | Sensor listener created |
| E,e (0x45, 0x65) | <-> | Error |
| F,f (0x46, 0x66) | <-> | Free data for custom purposes |
The group of commands
- Q – query
- A – query reply
- C – sensor discovery
- N – discovery reply
- Z – reset
- G – get sensor configuration
- S – set sensor configuration
are used to find and configure sensor units utilizing SSI-protocol.
The group of commands
- R – request sensor data
- V – data response
- D – data response with status field
are used to read sensor data infrequently.
For data streaming purposes are defined commands
- O – create sensor observer
- Y – observer created
- K – delete observer
- U – observer finished
- L – request sensor listener
- J – sensor listener created.
- V – data response
- M – data response with many data points
[edit] Point-to-point SSI
Point-to-point messaging with SSI can be done with SSI/UART. SSI UART message consists of a 3-byte UART header, SSI message as payload and an optional Cyclic redundancy check checksum. The use of checksum is defined by SSI message/command type, with lower case commands indicating the use of CRC. The header consists of start byte (0xFE), 2-byte (total) length of message and 2-byte bitwise Negation of length bytes to help identifying the frame start.
[edit] Networking SSI
SSI networking in a variable environment is done e.g. using nanoIP. In a typical case for using SSI, an individual message is not important, and so nanoUDP (simplified UDP defined by nanoIP) is used as the message format. If individual messages are important, nanoTCP can be used, as it provides flow control and retransmission, with the cost of message size and increase in network traffic.
A nanoUDP message consists of a 5-byte nanoUDP header, n-byte message payload and optional 2-byte CRC checksum. The header consists of one protocol byte, 2-byte message length (total length, including header and CRC), 1-byte source port and 1-byte destination port number. The destination port number should be 0x28 for SSI messages.
[edit] Version history
- 0.1 March 14, 2003
- 0.2 April 29, 2003
- 0.3 May 20, 2003
- 0.4 October 2, 2003
- 0.5 December 5, 2003, not compatible with previous
- 0.6 November 3, 2004
- 0.7 December 22, 2004
- 0.8 January 14, 2005
- 1.0 April 11, 2005
- 1.1 October 27, 2005
- 1.2 May 27, 2006, not compatible with previous
