2.4GHz NRF24L01 only sending when transmitting data?

Hello,
i'm not able to find information if the NRF24L01 modules are always sending (like WLAN or BlueTooth) or only in case of transmitting data. Sure, the receiver must be always on.

I will build up a network with different sensors and actors concentrated to one arduino, which is connected to my network with electrical LAN to prevent adding "noise" to the air. This is why i don't want to use WIFI or Bluetooth.

As i understand XBEE/ZigBEE does what i want, but these modules are much more expensive.

Regards,
Sascha

I can't send a link from my mobile phone but if you Google NRF24L01 you should find that information

Did you look at the code in the NRF24 Library Examples ? I would think that would tell you everything.
Have you installed that library yet ? If not , your post is premature.

From the datasheet my understanding is that there is no "background transmissions" on the NRF24L01, the transmitter is only active when sending a packet of data you've given it or when a receiver acknowledges receipt of a data packet. If you wanted to be certain, you can explicitly put a node in standby.

Look at the code.
My understanding is it has a payload, limited to 28 (or 32 ) bytes and once it sends that payload it can send another.

/*
 Copyright (C) 2011 J. Coliz <maniacbug@ymail.com>

 This program is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
 version 2 as published by the Free Software Foundation.
 */

/**
 * Example LED Remote
 *
 * This is an example of how to use the RF24 class to control a remote
 * bank of LED's using buttons on a remote control.
 *
 * On the 'remote', connect any number of buttons or switches from
 * an arduino pin to ground.  Update 'button_pins' to reflect the
 * pins used.
 *
 * On the 'led' board, connect the same number of LED's from an
 * arduino pin to a resistor to ground.  Update 'led_pins' to reflect
 * the pins used.  Also connect a separate pin to ground and change
 * the 'role_pin'.  This tells the sketch it's running on the LED board.
 *
 * Every time the buttons change on the remote, the entire state of
 * buttons is send to the led board, which displays the state.
 */

#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"

//
// Hardware configuration
//

// Set up nRF24L01 radio on SPI bus plus pins 9 & 10

RF24 radio(9,10);

// sets the role of this unit in hardware.  Connect to GND to be the 'led' board receiver
// Leave open to be the 'remote' transmitter
const int role_pin = A4;

// Pins on the remote for buttons
const uint8_t button_pins[] = { 2,3,4,5,6,7 };
const uint8_t num_button_pins = sizeof(button_pins);

// Pins on the LED board for LED's
const uint8_t led_pins[] = { 2,3,4,5,6,7 };
const uint8_t num_led_pins = sizeof(led_pins);

//
// Topology
//

// Single radio pipe address for the 2 nodes to communicate.
const uint64_t pipe = 0xE8E8F0F0E1LL;

//
// Role management
//
// Set up role.  This sketch uses the same software for all the nodes in this
// system.  Doing so greatly simplifies testing.  The hardware itself specifies
// which node it is.
//
// This is done through the role_pin
//

// The various roles supported by this sketch
typedef enum { role_remote = 1, role_led } role_e;

// The debug-friendly names of those roles
const char* role_friendly_name[] = { "invalid", "Remote", "LED Board"};

// The role of the current running sketch
role_e role;

//
// Payload
//

uint8_t button_states[num_button_pins];
uint8_t led_states[num_led_pins];

//
// Setup
//

void setup(void)
{
  //
  // Role
  //

  // set up the role pin
  pinMode(role_pin, INPUT);
  digitalWrite(role_pin,HIGH);
  delay(20); // Just to get a solid reading on the role pin

  // read the address pin, establish our role
  if ( digitalRead(role_pin) )
    role = role_remote;
  else
    role = role_led;

  //
  // Print preamble
  //

  Serial.begin(57600);
  printf_begin();
  printf("\n\rRF24/examples/led_remote/\n\r");
  printf("ROLE: %s\n\r",role_friendly_name[role]);

  //
  // Setup and configure rf radio
  //

  radio.begin();

  //
  // Open pipes to other nodes for communication
  //

  // This simple sketch opens a single pipes for these two nodes to communicate
  // back and forth.  One listens on it, the other talks to it.

  if ( role == role_remote )
  {
    radio.openWritingPipe(pipe);
  }
  else
  {
    radio.openReadingPipe(1,pipe);
  }

  //
  // Start listening
  //

  if ( role == role_led )
    radio.startListening();

  //
  // Dump the configuration of the rf unit for debugging
  //

  radio.printDetails();

  //
  // Set up buttons / LED's
  //

  // Set pull-up resistors for all buttons
  if ( role == role_remote )
  {
    int i = num_button_pins;
    while(i--)
    {
      pinMode(button_pins[i],INPUT);
      digitalWrite(button_pins[i],HIGH);
    }
  }

  // Turn LED's ON until we start getting keys
  if ( role == role_led )
  {
    int i = num_led_pins;
    while(i--)
    {
      pinMode(led_pins[i],OUTPUT);
      led_states[i] = HIGH;
      digitalWrite(led_pins[i],led_states[i]);
    }
  }

}

//
// Loop
//

void loop(void)
{
  //
  // Remote role.  If the state of any button has changed, send the whole state of
  // all buttons.
  //

  if ( role == role_remote )
  {
    // Get the current state of buttons, and
    // Test if the current state is different from the last state we sent
    int i = num_button_pins;
    bool different = false;
    while(i--)
    {
      uint8_t state = ! digitalRead(button_pins[i]);
      if ( state != button_states[i] )
      {
        different = true;
        button_states[i] = state;
      }
    }

    // Send the state of the buttons to the LED board
    if ( different )
    {
      printf("Now sending...");
      bool ok = radio.write( button_states, num_button_pins );
      if (ok)
        printf("ok\n\r");
      else
        printf("failed\n\r");
    }

    // Try again in a short while
    delay(20);
  }

  //
  // LED role.  Receive the state of all buttons, and reflect that in the LEDs
  //

  if ( role == role_led )
  {
    // if there is data ready
    if ( radio.available() )
    {
      // Dump the payloads until we've gotten everything
      bool done = false;
      while (!done)
      {
        // Fetch the payload, and see if this was the last one.
        done = radio.read( button_states, num_button_pins );

        // Spew it
        printf("Got buttons\n\r");

        // For each button, if the button now on, then toggle the LED
        int i = num_led_pins;
        while(i--)
        {
          if ( button_states[i] )
          {
            led_states[i] ^= HIGH;
            digitalWrite(led_pins[i],led_states[i]);
          }
        }
      }
    }
  }
}
// vim:ai:cin:sts=2 sw=2 ft=cpp

The most common libraries for the nRF24L01+ have a powerUp() / powerDown() method so you can explicitly switch it off after transmitting your data. There are no 'keep alive' type transmissions necessary to keep a data channel open or anything like that.

once it sends that payload it can send another.

For clarification, this is meant to be read as " it can send another if the code explicitly tells it to", and not intended to mean that it is a transmitter with an active transmission line open , after sending the payload.

SaschaH:
Hello,
i'm not able to find information if the NRF24L01 modules are always sending (like WLAN or BlueTooth) or only in case of transmitting data. Sure, the receiver must be always on.

I will build up a network with different sensors and actors concentrated to one arduino, which is connected to my network with electrical LAN to prevent adding "noise" to the air. This is why i don't want to use WIFI or Bluetooth.

As i understand XBEE/ZigBEE does what i want, but these modules are much more expensive.

Regards,
Sascha

Neither WLAN or bluetooth to my knowledge are full-duplex, old analog mobile phones used to
be full-duplex, but it was very complex/expensive to make it work well as the power ratio between
transmit and receive is 150dB or something crazy like that, requiring very good filtering and screening.
With digital packet radio systems time division multiplexing or CSMA are employed. Always transmitting
is very anti social in fact. Analog phones used two widely separated channels to accomplish full-duplex.

The nRF24L01 does what you tell it when you tell it - transmit a packet, listen for a packet. It
has configurable auto-acknowledge I believe, but it does not implement any real protocol - that's
for software higher up the stack to manage.

ZigBee's have a protocol stack in firmware.