Level II Specifics

Also check VSCP over TCP/IP which have more Level II specifics for the lower levels.

Level II nodes are intended for media with higher bandwidth then Level I nodes and no nickname procedure is therefore implemented on Level II. As result of this the full GUID is sent in each packet.

The header for a level II event is defined as

// This structure is for VSCP Level II
typedef struct _vscpMsg {
     _u16 crc; // CRC checksum
     _u8 *pdata; // Ponter to data. Max 487 (512- 25) bytes
     // Following two are for daemon internal use
     _u32 obid; // Used by driver for channel info etc.
     _u32 timestamp; // Relative time stamp for package in microseconds
     // CRC should be calculated from
     // here to end + datablock
     _u8 head; // bit 765 prioriy,
     // Priority 0-7 where 0 is highest.
     // bit 4 = hardcoded, true for a hardcoded device.
     // bit 3 = Dont calculate CRC,
     // false for CRC usage.
     _u16 vscp_class; // VSCP class
     _u16 vscp_type; // VSCP type
     _u8 GUID[ 16 ]; // Node address MSB -> LSB
     _u16 sizeData; // Number of valid data bytes
} vscpMsg;

The biggest differences is that the GUID is sent in each event and that both class and type has a 16-bit length.

The CRC is calculated using the CCITT polynomial CRC polynoms used by VSCP

The max size for a Level II event is 512 bytes and as the header takes up 25 bytes the payload or datapart can take up max 487 bytes. This can seem a bit strange looking at the above structure but in a datagram or aother package not all of the above members are present. The format in a stream is

#define VSCP_UDP_POS_HEAD 0
#define VSCP_UDP_POS_CLASS 1
#define VSCP_UDP_POS_TYPE 3
#define VSCP_UDP_POS_GUID 5
#define VSCP_UDP_POS_SIZE 21
#define VSCP_UDP_POS_DATA 23
#define VSCP_UDP_POS_CRC len - 2

As is noted the obid and timestamp is not present in the actual stream and is only inserted by the driver interface software.

Level I events can travel in the Level II world. This is because all Level I events are repleted in Class=1024. As nicknames are not available on Level II they are replaced in the events by the full GUID. This is an important possibility in larger installations.

A message from a node on a Level I that is transfered out on a Level II can have the nodes own GUID set or the GUID of the interface between the Level I and the Level II segment. Which method to choose is up to the implementor as long as the GUID's are unique.

For interfaces the machine MAC address, if available, is a good base for a GUID which easily can map to real physical nodes that are handled by the interface. By using this method each MAC address gives 65536 unique GUID's.

Other methods to generate GUID's s also available form more information see Appendix A.

VSCP level II events can be presented as XML data. Format is

<?xml version = "1.0" encoding = "UTF-8" ?>
 
<!-- Version 0.0.1    2007-09-27 -->
 
<event>
    <class>Eventclass is numerical form or CLASSx:numerical form</class>
    <type>Event type in numerical form.</type>
    <guid>ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00</guid>   <!-- GUID of sending node -->
    <timestamp>YYYY-MM-DD HH:MM:SS|millieconds since epoc</timestamp>
    <data>Comma separated list with event data. Hex values (precede with '0x')and decimal values allowed.</data>
</event>