NRF24L01 data type

Projects Programming
1

Hello, I am using Dejan Nedelkovski's reference code for the RX side. My question....

If I load a byte on the TX side of 255 and send it via NRF. Is this a character or the integer value going across? What should land in data.a if I am sending 1byte = 255?
In some examples I see atoi(received) to convert character to byte being used but not with this library. Any insight would be appreciated. I am still coding and wiring up things so I can't test out at this time.

/*
  Arduino Wireless Communication Tutorial
        Example 1 - Receiver Code

  by Dejan Nedelkovski, www.HowToMechatronics.com

  Library: TMRh20/RF24, https://github.com/tmrh20/RF24/
*/

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

RF24 radio(7, 8); // CE, CSN

const byte address[6] = "00001";

// Max size of this struct is 32 bytes - NRF24L01 buffer limit
struct Data_Package {
  byte a = 0;
  byte b = 125;
  byte c = 255;
  int d = 1024;
  float e = 3.141592;
  String f = "Test";
};

Data_Package data; //Create a variable with the above structure

void setup() {
  Serial.begin(9600);
  radio.begin();
  radio.openReadingPipe(0, address);
  radio.setPALevel(RF24_PA_MIN);
  radio.startListening();
}

void loop() {
  // Check whether there is data to be received
  if (radio.available()) {
    radio.read(&data, sizeof(Data_Package)); // Read the whole data and store it into the 'data' structure
  }
  Serial.print("a: ");
  Serial.print(data.a);
  Serial.print(" b: ");
  Serial.print(data.b);
  Serial.print(" c: ");
  Serial.print(data.c);
  Serial.print(" d: ");
  Serial.print(data.d);
  Serial.print(" e: ");
  Serial.print(data.e);
  Serial.print(" f: ");
  Serial.println(data.f);
}
2

NRF24L01s just transfer a buffer, regardless of the bit pattern contained within.

The buffer can automatically be filled with zeros, if a fixed buffer size is used,
and the written buffer was shorter than this fixed size.

Packing and unpacking of the raw data, removing control bits, checking address and checksum,
is handled transparently by hardware.

3

Did that tutorial have an example of a struct containing a String datatype? It is unlikely to be interpreted correctly on the on the receiving side. Use a char array instead.

4

Check out the code I enclosed in my post. Lifted completely without modification. he does have 6 different data types declared in the struct int, decimal and text. So I am not sure if under the hood, there is a conversion of sorts going on.

5

The String data type will not work with that code. The struct only holds the overhead data for the String object (6 bytes or so). The actual characters are held in dynamically-allocated memory. That data will not transfer over the NRF24L01 link. Only the overhead information will transfer and this will be meaningless on the RX processor.

6

Good thing all I need to pass is two bytes representing two potentiometers each with 0 ~ 255 values. Good to know about the string. Weird this has been around a long time, I wonder why no one corrected it.

7

Indeed it is as in the tutorial which appears here: https://howtomechatronics.com/tutorials/arduino/arduino-wireless-communication-nrf24l01-tutorial/ Under the heading: Example 3 – Sending multiple variables in a single package

There even appears to be a convincing looking screen shot of it working. I guess then that the output shown is from the transmitter side.

8

Look at the receiver sketch, the struct is declared with default values that match the data used in the sender sketch, and both sketches are basically identical through the start of setup(). Just got lucky and the compiler put all the variables in identical locations, so the String prints correctly.

The correct data would be printing BEFORE anything was actually received via the radio link, and there really is no way with that code to determine if the radio link works at all unless there is an error in the received data.

9

Indeed. The receiver is printing default output irrespective of whether or not the transmitter is sending anything. However, I would have thought that any successful transmission would overwrite or otherwise corrupt the default value of the String variable replacing it with some representation of its 6 byte object handle (or similar).
Anyway, I suppose the lesson here is to be sceptical of this author's tutorials.