 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Simple Sensor Interface protocol" – news ·newspapers ·books ·scholar ·JSTOR(December 2015) (Learn how and when to remove this message) |
TheSimple Sensor Interface (SSI)protocol is a simple communications protocol designed for data transfer between computers or user terminals and smart sensors.[citation needed]
The SSI protocol has been developed jointly byNokia,Vaisala,Suunto, Ionific, Mermit andUniversity of Oulu and released its first version in March 2003. Currently SSI is being developed within the Mimosa Project, part of theEuropean UnionFramework Programmes for Research and Technological Development.
The SSI protocol is used in point-to-point communications overUART and networking nanoIP applications. SSI also provides polling sensors and streaming sensor data. ForRFID sensor tags SSI specifies memory map for sensor data.
The criteria for SSI protocol development are:
Sample implementation of the SSI protocol forMSP430microcontrollers will be published asopen source during August 2006 by Nokia.
An SSI message consists of a 2-byte header and ann-byte payload. The header consists of a one byte address (wildcard is '?', 0x3F inASCII) and a one byte message/command type. The different possible values for the message/command type are presented in 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:
are used to find and configure sensor units utilizing the SSI-protocol.
The group of commands:
are used to read sensor data infrequently.
For data streaming purposes defined commands are:
Point-to-point messaging with SSI can be done with SSI/UART. An SSI UART message consists of a 3-byte UART header, an SSI message as the payload and an optionalCyclic redundancy checkchecksum. The use of a checksum is defined by the SSI message/command type, with lower case commands indicating the use of CRC. The header consists of a start byte (0xFE), a 2-byte (total) length of the message and a 2-bytebitwiseNegation length to help identify the frame start.
SSI networking in a variable environment is done using nanoIP. In a typical case using SSI, an individual message is not important, and so nanoUDP (simplifiedUDP 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 at a cost of message size and increase in network traffic.
A nanoUDP message consists of a 5-byte nanoUDP header, ann-byte message payload and an optional 2-byte CRC checksum. The header consists of one protocol byte, a 2-byte message length (total length, including header and CRC), a 1-byte source port and a 1-byte destination port number. The destination port number should be 0x28 for SSI messages.