Reserved System Message Types

Macros
#define	NETWORK_ADDR_RESPONSE   128
#define	NETWORK_PING   130
#define	EXTERNAL_DATA_TYPE   131
#define	NETWORK_FIRST_FRAGMENT   148
#define	NETWORK_MORE_FRAGMENTS   149
#define	NETWORK_LAST_FRAGMENT   150
#define	NETWORK_ACK   193
#define	NETWORK_POLL   194
#define	NETWORK_REQ_ADDRESS   195

Detailed Description

Reserved network message types

The network will determine whether to automatically acknowledge payloads based on their general RF24NetworkHeader::type.

• User types (1 - 127) 1 - 64 will NOT be acknowledged
• System types (128 - 255) 192 - 255 will NOT be acknowledged

System types can also contain message data.

Macro Definition Documentation

NETWORK_ADDR_RESPONSE

#define NETWORK_ADDR_RESPONSE   128

A NETWORK_ADDR_RESPONSE type is utilized to manually route custom messages containing a single RF24Network address.

Used by RF24Mesh

If a node receives a message of this type that is directly addressed to it, it will read the included message, and forward the payload on to the proper recipient.

This allows nodes to forward multicast messages to the master node, receive a response, and forward it back to the requester.

NETWORK_PING

#define NETWORK_PING   130

Messages of type NETWORK_PING will be dropped automatically by the recipient. A NETWORK_ACK or automatic radio-ack will indicate to the sender whether the payload was successful. The time it takes to successfully send a NETWORK_PING is the round-trip-time.

EXTERNAL_DATA_TYPE

#define EXTERNAL_DATA_TYPE   131

External data types are used to define messages that will be passed to an external data system. This allows RF24Network to route and pass any type of data, such as TCP/IP frames, while still being able to utilize standard RF24Network messages etc.

• Linux

  Linux devices (defined with RF24_LINUX macro) will buffer all data types in the user cache.

• Arduino/AVR/Etc

  Data transmitted with the type set to EXTERNAL_DATA_TYPE will not be loaded into the user cache.

External systems can extract external data using the following process, while internal data types are cached in the user buffer, and accessed using network.read() :

uint8_t return_type = network.update();
if(return_type == EXTERNAL_DATA_TYPE){
    uint16_t size = network.frag_ptr->message_size;
    memcpy(&myDataBuffer, network.frag_ptr->message_buffer, network.frag_ptr->message_size);
}

Examples

Network_Priority_RX.ino, and Network_Priority_TX.ino.

NETWORK_FIRST_FRAGMENT

#define NETWORK_FIRST_FRAGMENT   148

Messages of this type designate the first of two or more message fragments, and will be re-assembled automatically.

NETWORK_MORE_FRAGMENTS

#define NETWORK_MORE_FRAGMENTS   149

Messages of this type indicate a fragmented payload with two or more message fragments.

NETWORK_LAST_FRAGMENT

#define NETWORK_LAST_FRAGMENT   150

Messages of this type indicate the last fragment in a sequence of message fragments. Messages of this type do not receive a NETWORK_ACK

NETWORK_ACK

#define NETWORK_ACK   193

Messages of this type signal the sender that a network-wide transmission has been completed.

• Not fool-proof

  RF24Network does not directly have a built-in transport layer protocol, so message delivery is not 100% guaranteed. Messages can be lost via corrupted dynamic payloads, or a NETWORK_ACK can fail (despite successful transmission of the message).

• Traffic analysis

  NETWORK_ACK messages can be utilized as a traffic/flow control mechanism. Transmitting nodes that emit NETWORK_ACK qualifying messages will be forced to wait, before sending additional data, until the payload is transmitted across the network and acknowledged.

• Different from Radio ACK Packets

  In the event that the transmitting device will be sending directly to a parent or child node, a NETWORK_ACK is not required. This is because the radio's auto-ack feature is utilized for connections between directly related network nodes. For example: nodes 01 and 011 use the radio's auto-ack feature for transmissions between them, but nodes 01 and 02 do not use the radio's auto-ack feature for transmissions between them as messages will be routed through other nodes.

  Multicasted messages do use the radio's auto-ack feature because of the hardware limitations of nRF24L01 transceivers. This applies to all multicasted messages (directly related nodes or otherwise).

  Remarks

  Remember, user messages types with a decimal value of 64 or less will not be acknowledged across the network via NETWORK_ACK messages.

  Note

  NETWORK_ACK messages are only sent by the last node in the route to a target node. ie: When node 00 sends an instigating message to node 011, node 01 will send the NETWORK_ACK message to 00 upon successful delivery of instigating message to node 011.

NETWORK_POLL

#define NETWORK_POLL   194

Used by RF24Mesh

Messages of this type are used with multi-casting , to find active/available nodes. Any node receiving a NETWORK_POLL sent to a multicast address will respond directly to the sender with a blank message, indicating the address of the available node via the header.

NETWORK_REQ_ADDRESS

#define NETWORK_REQ_ADDRESS   195

Used by RF24Mesh

Messages of this type are used to request information from the master node, generally via a unicast (direct) write. Any (non-master) node receiving a message of this type will manually forward it to the master node using a normal network write.