Content deleted Content added
m template name update, parameter |
m More citations needed |
||
| (10 intermediate revisions by 7 users not shown) | |||
Line 1:
{{More citations needed|date=December 2015}}
The '''
The SSI protocol has been developed jointly by [[Nokia]], [[Vaisala]], [[Suunto]], Ionific, Mermit and [[University of Oulu]] and released its first version in March 2003. Currently SSI is being developed within the
▲The '''SSI''' ("'''Simple Sensor Interface'''") protocol is a simple communications protocol designed for data transfer between computers or user terminals and smart sensors. The SSI protocol is an [[Application layer]] protocol as in the [[OSI model]].
▲The SSI protocol has been developed jointly by [[Nokia]], [[Vaisala]], [[Suunto]], Ionific, Mermit and [[University of Oulu]]. Currently SSI is being developed within the [http://www.mimosa-fp6.com/ Mimosa project], part of the [[European Union]] [[Framework Programmes for Research and Technological Development]].
The 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.
Line 16 ⟶ 15:
== SSI message structure ==
An SSI message consists of a 2-byte header and an ''n''-byte payload. The header consists of a one byte address (wildcard is '?', 0x3F in [[ASCII]]) and a one byte message/command type. The different possible values for the message/command type are presented in SSI v1.2 command base.
=== SSI v1.2 command base ===
{| class="wikitable"
|-
! Command byte
Line 26 ⟶ 25:
! 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
Line 74 ⟶ 73:
| 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
Line 107 ⟶ 106:
|}
The group of commands
*
*
*
* Z – reset
▲*Z – reset
*
▲*S – set sensor configuration
are used to find and configure sensor units utilizing the SSI-protocol.
The group of commands:
* R – request sensor data
*
*
*D – data response with status field▼
are used to read sensor data infrequently.
For data streaming purposes defined commands are:
* O – create sensor observer
*
*
*
*
*
*
=== Point-to-point SSI ===
Line 146 ⟶ 140:
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 (simplified [[User Datagram Protocol|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 at a cost of message size and increase in network traffic.
A nanoUDP message consists of a 5-byte nanoUDP header, an ''n''-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.
== Version history ==
Line 161 ⟶ 155:
*1.1 October 27, 2005
*1.2 May 27, 2006, not compatible with previous
== References ==
{{Reflist}}
== External links ==
* [http://www.cwc.oulu.fi/nanoip/ nanoIP]
| |||