nRF24L01 programming

I’m hoping someone can offer some guidance. Using the attached codes I have successfully programmed two devices to act as transmitter and receiver, sending and receiving a simple code and illuminating an LED. I have expanded this to accept commands, from two separate buttons, illuminating separate LEDs. Fine. BUT, I want to expand further and have come up against a problem. Please refer to TRANSMIT CODE line 18 and RECEIVE CODE line 20.

TRANSMIT: 18 SentMessage[0] = 111;

RECEIVE: if (ReceivedMessage[0] == 111) // Indicates switch is pressed

The setup works fine when the messages are either 111, or 222 for both transmitter and receiver, but will not work for 333, 444, etc.

This obviously greatly limits expanding the functionality of the devices. Can anyone explain this and advise how to get around this problem? Thanks in advance.

tx-rx_Codes_brainybits.txt (2.3 KB)

Please post your code as regular .ino files, or, as the programs are short, just include the code in your next Reply. The line numbers in the text file just screw everything up.

In the meantime this Simple nRF24L01+ Tutorial may be of interest.


Thanks and also for the link. I have a couple of nRF24L01 packages already built for weather data transmission and command transmission. I am trying to send several different “actuation” commands this time.

Well, the last time I posted my code, I was reprimanded for NOT including and referencing line numbers as the responder stated it was not easy to follow the post explanation/problem I was trying to solve.

Since my post, I’ve done a bit more investigating into my current problem and have found that the transmit/receive does work OK provided that the 3 digit send/recv int value is somewhere below 250. For some reason I was fixated on the 111, 222, 333, etc. format. Therefore, problem solved, but could you provide some quick insight into what is happening? While I have a fair amount of general Arduino experience, I am rather novice when it comes to programming relating to package sizes, package arrays, etc. and have not been too successful in finding detailed tutorials on this subject on the internet opting for using and modifying codes I have found.

ino codes attached.

nRF24L01_Receiver_brainybits.ino (1 KB)

nRF24L01_Transmitter_brainybits.ino (1.04 KB)

Change this

radio.write(SentMessage, 1); // Send value through nRF24L01


radio.write(SentMessage, sizeof(SentMessage); // Send value through nRF24L01

You have defined SentMessage as an int which is 2 bytes long but in your code you are only sending 1 byte - hence the upper limit of 255. Likewise on the receiving side.


PS ... This was crap

I was reprimanded for NOT including and referencing line numbers

every respectable text editor displays line numbers.

aha! a very simple solution...thank I mentioned, I am not yet sufficiently versed in packages to have caught that.

so, I suppose instead of defining it as int, I could use char and then use alphabetic values, like ON, OFF and so forth?

so, I suppose instead of defining it as int, I could use char and then use alphabetic values, like ON, OFF and so forth?

You will have to explain what is in your mind - why you are considering that alternative.

You can certainly send strings of characters if you want to. However if I wanted to signal something as simple as "ON" or "OFF" I would just send 'N' or 'F'


It was just a thought...your idea of N, or F would do the job too. One final request, do you know of a good internet source for detailed instruction on packages, package arrays and the nuances of that type of programming? Quite often I find information that says, 'do this, or do that' without the background as to why. My 'aha' moment from your explanation is a case in point. Thanks again for your help.

detailed instruction on packages, package arrays and the nuances of that type of programming?

What do you mean by "packages"?

I wonder if you need to study arrays and structs in C++ programming?


perhaps my terminology is incorrect...I mean the data in a packet/package being sent/received...byte sizing, etc. My only understanding of arrays is dealing with elementary programming such as how to light a string of LEDs. Not familiar with structs at all. For example, trying to read/understand large portions of documents such as RF24 Class Reference is particularly troublesome because for the most there is very little explanation. Your link will help to some extent in this regard. Programming wireless transmission/reception functions (Bluetooth, WiFi, RF24), rather than other C+ functions are the areas that give me the most problems and have me scratching my head. I can design a bridge or an oil platform, but my background is not in IT.

If you have a specific question I will try to help.

The nRFL2401+ transceivers send a “group” of bytes (max of 32 in one message).

Data is stored in the computer memory in bytes - one after the other with no boundaries or markers between them. An int requires 2 bytes. A long or a float requires 4 bytes. When you define a variable in your program you are telling the compiler how to deal with a byte (or group of bytes). What we see as the name of a variable is actually translated by the compiler into the address of the first byte of the variable. An array is a collection of variables all of the same type. You can use a struct to create a complex type of data - for example with space for firstName, lastName, gender, age and salary. At the bottom of it all is a series of bytes holding the data. Whatever may be the nature of the data in the eyes of the programmer, it is the underlying bytes that the nRF24 sends and receives. In general you give the nRF24 the address of the start of the range of bytes and the number of bytes to send, and similar for receiving.

Don’t know if that helps or hinders.


Thank you for the info and very much for your continued help. I could probably ask more questions than you want to spend time answering. Perhaps I should check out amazon for a book that would delve into more complicated areas first, like "C++ Programming for Dummies" !

I can think of one question on wireless transmission, but not RF24, so maybe this will be outside your area. I built a slick PIR-activated ESP8266 WiFi e-mailer (gmail) that will alert us if someone enters our barn, or if one of the horses gets loose (the barn is ~1,000ft from the house so we cannot directly see what's going on). Besides a simple e-mail with a title and couple lines of text, at some point in the future I would like to add an attachment that could be a wav or jpg file, for example. Just haven't found a good tutorial, or example, on the internet yet that will instruct on adding the language for an attachment. I've looked at IfTTT, IoT and some other websites also.

I can think of one question on wireless transmission, but not RF24, so maybe this will be outside your area.

Yes. I have a couple of ESP8266 modules but I have done very little with them. All the (limited) web programming I have done has been on a PC using Python and Javascript.


I've been browsing books on amazon. Would you recommend a book on Arduino programming, or C, C++? My own thought would be one specific to the C languages as it might give me more depth than Arduino alone.

I am not qualified to recommend beginners books because I knew a lot of programming before I got my first Arduino. I had a bief browse in Arduinos for Dummies in a shop and it seems good. Years ago I found Sailing for Dummies really excellent.

Unfortunately there are few bookshops now and even fewer of them stock text books so you can browse to see which one best suits your own learning style.

There are tons (tonnes) of online tutorials for learning most computer stuff. I have used from time to time for Python and it also covers other languages.


thanks much

I've been looking at the XBee radios and was wondering if you have ever used the them and do they compare with the nRF24L01, or are they apples & oranges? it seems that they have much more data thruput capability.

I have not used XBees as they seem very expensive. AFAIK they could be used as an alternative to a pair of nRF24s - but they are not inter-operable with nRF24s