Optimized RF24Network Layer v2.0.0
2024 - Optimized RF24 Network Layer for NRF24L01 & NRF52x radios
No Matches
Reserved System Message Types


#define NETWORK_PING   130
#define EXTERNAL_DATA_TYPE   131
#define NETWORK_ACK   193
#define NETWORK_POLL   194

Detailed Description

Reserved network message types

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

System types can also contain message data.

Macro Definition Documentation



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.


#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.


#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);
Definition RF24Network.h:103
Network_Priority_RX.ino, and Network_Priority_TX.ino.



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



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



Messages of this type indicate the last fragment in a sequence of message fragments. Messages of this type do not receive a 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).
    Remember, user messages types with a decimal value of 64 or less will not be acknowledged across the network via NETWORK_ACK messages.
    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.


#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.



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.