Integration Guide

SMK900 Integration Guide Revision 4
Protocol-formatted Messages
Protocol Formats
SMK900 module can work in one of two serial data modes - transparent or protocol. Transparent mode
requires no data formatting, but cannot leverage the embedded node addressing schemes, nor can
access configuration and VM upload/erase/check/execute functions. Thus, transparent mode is adapted
mainly for simple drop-in serial wire replacement for point-to-multipoint applications.
Thus, a gateway that needs to send messages to a specific node, or a node replying to said gateway, must
use protocol formatting if any advanced functionality other than simple ASCII message broadcast is
needed, such as access to sensor I/O commands, configuration commands and replies, event
monitoring, etc. All protocol-formatted messages have a common header as shown in Figure :
0
1
2
3
4...
SOP
Length
(LSByte)
Length
(MSByte)
PktType
Variable number of arguments ...
The scale above is in bytes.
The Start-of-Packet (SOP) character, 0xFB, is used to mark the beginning of a protocol-formatted message
and to assure synchronization in the event of a glitch on the serial port at startup.
This is followed by two length bytes, in Little-Endian ordering (lowest-significant byte first). This 16-bit
value corresponds to the length of the remainder of the message following the length bytes themselves,
i.e. the length of the entire message - 3.
The Packet Type (PktType) byte specifies the type of message. It is a bitfield-oriented specifier, decoded
as follows:
Bit(s)
Meaning
7
Address send back request bit
6
Reserved for future use
5
Event - this bit is set to indicate an event message
4
Reply - this bit is set to indicate a message is a reply
3..0
Type - these bits indicate the message type
Message
Messages generated on the serial interface by the user are referred to as host messages, and have a
PktType reply bit (4) cleared. Messages generated on the serial interface by the radio are referred to as
reply or event messages, and have either bit 4 (replies) or bit 5 (event) of the PktType byte set. For most
commands, there is a corresponding reply message, which is either an acknowledgement message.
Errors are usually flagged using event messages. Messages received by the radio and relayed back to
user, such as node reply messages, are flagged as event messages as well. Note that for all quantities
encoded using multi-byte, the byte ordering is Little-Endian, except for text strings. Little-Endian byte
order places the lowest order byte in the left-most byte of the argument and the highest order byte in
the right-most byte of the argument.
A command sent from the host to a module locally via serial port in order to initiate an action locally, or
to read/write to the module locally, is the default type of message. However, there is also another type
of message, which are called air command wrapped messages. Those are typically akin to local destination
messages, but wrapped around a meta-message, which, combined with a destination MAC address,
allows to execute said command at a remote transceiver node location with said MAC address as if that
command was locally executed at this remote node location. Thus, it is possible to use the same
22