Murata Electronics North America DNT24 Manual Do Utilizador
www.Murata.com
Technical support +1.678.684.2000
Page 33 of 83
© 2015 by Murata Manufacturing Co. Ltd.
E-mail:
tech_sup@murata.com
DNT24 Integration Guide – 03/04/15
7.0 DNT24 Protocol-formatted Messages
7.1 Protocol Formats
DNT24 modules can work in one of two serial data modes - transparent or protocol. Transparent mode
requires no data formatting, but is limited to sending data to either a single destination or broadcasting
data to all destinations. A node that needs to send messages to multiple individual destinations must use
protocol formatting unless the data being sent includes addressing information. Protocol formatting is also
required for configuration commands and replies, and sensor I/O commands, replies and events. All pro-
tocol-formatted messages have a common header as shown in Figure 7.1.1:
requires no data formatting, but is limited to sending data to either a single destination or broadcasting
data to all destinations. A node that needs to send messages to multiple individual destinations must use
protocol formatting unless the data being sent includes addressing information. Protocol formatting is also
required for configuration commands and replies, and sensor I/O commands, replies and events. All pro-
tocol-formatted messages have a common header as shown in Figure 7.1.1:
0
1
2
3 …
SOP
Length
PktType
variable number of arguments …
Figure 7.1.1
The scale above is in bytes.
The Start-of-Packet (SOP) character, 0xFB, is used to mark the beginning of a protocol-formatted mes-
sage and to assure synchronization in the event of a glitch on the serial port at startup.
sage and to assure synchronization in the event of a glitch on the serial port at startup.
The Length byte is defined as the length of the remainder of the message following the length byte itself,
or the length of the entire message - 2.
or the length of the entire message - 2.
The Packet Type (PktType) byte specifies the type of message. It is a bitfield-oriented specifier, decoded
as follows:
as follows:
Bits 7..6
Reserved for future use
Bit 5
Event - this bit is set to indicate an event message
Bit 4
Reply - this bit is set to indicate a message is a reply
Bits 3..0
Type - these bits indicate the message type
As indicated, the lower four bits (3..0) specify a message type. Bit 4 indicates that the message is a reply.
A reply message has the original command type in bits 3..0, with Bit 4 set to one. Bit 5 indicates an event
message. Arguments vary in size and number depending on the type of message and whether it is a
message sent from the host, or is a reply or event message from the radio. See Section 7.3 below.
A reply message has the original command type in bits 3..0, with Bit 4 set to one. Bit 5 indicates an event
message. Arguments vary in size and number depending on the type of message and whether it is a
message sent from the host, or is a reply or event message from the radio. See Section 7.3 below.
7.2 Message Types
Messages sent to the module on the serial interface by the user are referred to as host messages. Mes-
sages generated on the serial interface by the radio are referred to as reply or event messages. Host
messages carry commands. For most commands, there is a corresponding reply message. For example,
when the host sends a TxData command message, the radio can return a TxDataReply message to indi-
cate the status of the transmission - whether it succeeded or failed. To assist in interpreting the com-
mand-reply data flow, the direction is indicated by the high nibble in the message type. For example, an
EnterProtocolMode command from the host is a message type 0x00, and the EnterProtocolModeReply
from the radio is a message type 0x10.
sages generated on the serial interface by the radio are referred to as reply or event messages. Host
messages carry commands. For most commands, there is a corresponding reply message. For example,
when the host sends a TxData command message, the radio can return a TxDataReply message to indi-
cate the status of the transmission - whether it succeeded or failed. To assist in interpreting the com-
mand-reply data flow, the direction is indicated by the high nibble in the message type. For example, an
EnterProtocolMode command from the host is a message type 0x00, and the EnterProtocolModeReply
from the radio is a message type 0x10.
Event messages from a DNT24, such as received data or status announcements make up a third catego-
ry of messages. Event messages, including RxData, RxEvent and Announce packets are indicated by
0x20 in the high nibble of the type byte. If multiple arguments are to be provided, they are to be concate-
nated in the order shown in Section 7.3 below. Little-Endian byte order is used for all multi-byte
ry of messages. Event messages, including RxData, RxEvent and Announce packets are indicated by
0x20 in the high nibble of the type byte. If multiple arguments are to be provided, they are to be concate-
nated in the order shown in Section 7.3 below. Little-Endian byte order is used for all multi-byte