Back to Specification
Physical Level

Description of the VSCP General RF protocol

:!:Preliminary:!:

Comparision to "standard" protocols

Most standard protocols expect delivery to be point to point. One source have one consumer. For VSCP this should be rephrased to one source and an unknown number of consumers. So to implement VSCP over a standard protocol a frame is sent to each node in turn expecting an acknowledge frame in return from the node. Thus the number of frames sent is 2n where n is the number of nodes assuming transmission without faults. In a mesh network nodes has to know their neighbors so some additional traffic is needed for this.

For the VSCP RF Low level protocol one message is broadcasted from the originating node. All nodes that receive it will repeat it. Thus a total of n messages will be sent out and at the same time mesh networks will be handled automatically. The bandwidth taken is half that of the standard approach. Built into this is also the fact that a node that misses a message get several chances to acquire the message from repeating nodes. Something that is particularly good for RF where the most common disturbance is short bursts.

In VSCP when we send an event we don't want to know too much about the receiving nodes. We send out something we think might interest the world and each individual in this world makes a decision if they are interested in it or not. This helps us to keep the abstraction level high and we don't have to keep track of other nodes on the bus. Note however that for this protocol an originating node can keep track of its neighbors and retransmit a message if some node(s) don't repeat the message (confirms the message).

Operation Frequency

Nothing is said about the used transmission frequency in this document. VSCP over RF is designed to work on 433MHz as well as 868/915MHz and 2.4GHZ and other frequencys of choice

How many nodes can be connected?

Theoretically 254 nodes can be connected. This number is theoretical and will be limited by real world implemention data such as transmission speeds and other limiting factors.

How is the address for a node set?

A node address can be programmed in hardware or through switches. In this case the node address is hard coded and the hard coded bit, (bit 15), of the address should be set. For hard coded nodes the address is made up of two parts a common segment code (upper seven bits) and a unique Node code (lower eight bits).

For soft coded addresses a nickname discovery mechanisms is used when the node flirts is connected to the network. This nickname address lives with the node forever after it has been set.

The nickname discovery is simple and implemented in the following way:

  1. A node connected to the network sends out a “nickname probe” with its own address as 0xff and the destination address set to zero. It then waits for a response from node zero ( possible master). If received it will wait and let the master node set a nickname. If not received the discovery goes on.
  2. The node send out a “nickname probe” with node id 1 and waits for an answer. And continue with this with increasing nicknames until it gets a timeout.
  3. To make certain that the node found is indeed a free nickname it repeats the discovery three times with this nickname id before acquiring it as its own. If a repose is revived during this the process is started all over from the beginning.

As a variant of the above suitable for installers a node can be setup by using the nickname discovery mechanism and have a installer tool which is setup as master. The node will then find the master when it is started up and wait for the master to set its address. After that other configuration parameters can also be set and the node is ready for installation and the installation tool /the master is not needed anymore.

Packet format

Preamble

Preamble to sync the data reception. Preamble is 0xdd followed by 0x16

Flags byte

A flag byte with protocol information.

Bit 7 - VSCP Class bit 9.
Bit 6 - House Code MSB.
Bit 5 - House Code
Bit 4 - House Code LSB
Bit 3 - Datasize MSB.
Bit 2 - Datasize.
Bit 1 - Datasize LSB.
Bit 0 - Datasize LSB.
The node id

The address for a node is set by a 8-bit number where the top most bit, bit 7, is used as a hard coded bit. This leaves room for 2^7-2 hard coded and 2^7-1 nickname nodes.

Two addresses are reserved. 0 which is reserved for a master and 0xff which is the broadcast address.

Node address 0x00 is master address (may or may not be present).
Node address 0x80 of master for hard coded nodes.
Node address 0xff is broadcast for both hard coded and soft coded nodes.

Hardcoded nodes are devided into segment code (upper three bits) and Node code (lower four bits).

index byte

The index byte consist of two parts.

bit 7-4 This index is increase by one for every new message a node sends out.  
bit 3-0 Is set to zero for a new message. And increased by one before retransmiting a frame.

When a node received a message it should resend the message if

If the node is not the originating node of the message.
If it already received a message with and id built from the node-id + bit 7-4 of the index byte.

In all other cases the node retransmit the message as it is with the original node id and bits 7-4 of this byte intact but it increase bit 3-0 by one.

Originating address

The address for the node that send this message.

This is the same address used as above for the originating node but all nodes that repeat a message inset there own node id here.

class

VSCP class MSB byte. Bit nine is in flags byte.

type

VSCP type MSB byte.

optional data block

VSCP Level I data. Max eight bytes.

CRC MSB/LSB

An implementor specific CRC from node-id and the full package length excluding the CRC itself.

Node id + index byte forms a unique message id (UMID).

To be able to determine if it has received messages a node should have a cache where it stores UMID's of sent and received messages. The cache should delete the oldest id when it puts in a new id into the cache. The minimum size of this cache is yet to be defined.

In a none mesh environment the implementor can choose to just retransmit the header including the CRC to save bandwidth.

Message transmission

A node check for a carrier signal on the selected frequency band. If it is present it waits for as many milliseconds as stated by its MSB GUID byte. It then tries again and if a carrier is still present it waits the amount of milliseconds given by its GUID MSB less one and continue in that fashion until it can complete the transmission.

When a frame has been sent the node should listen for at least one repeat of its own transmitted frame and resend it if no repeat is received. The timeout is still to be defined.

Message Reception.

A received messages UMID is checked (the 20 most significant bits) if its in the cache. If its not there it is retransmitted after increasing the lower four bits by one.

If the node has a message of its own to send this retransmission should be performed before that transmission.

A protocol implementor can, but should preferable not, design a node that don't retransmit received frames. This can be useful for systems where some extra layer is present that secure arrival of frames. It should be noted that mesh capabilitiues will be list by doing this.

Dumb Nodes

For some nodes it is important to keep the processing overhead down to a minimum. This can be due to the node being battery powered or extremly low on hardware resources. A typical dumb node is one that sends out a measurement such as a temperature on even intervals. It normally does not matter if this data is lost from time to time.

A dumb node can have a hard coded address and only send out data. It does not have to repeat data or implement the nickname algorithm. It can also have the nickname discovery algorithm implemented and acquire its address that way.

vscp_specification_-_vscp_level_ii_over_rf_and_plc.txt · Last modified: 2010/08/19 01:55 (external edit)
Public Domain
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0