NRF24L01+ in Python

[blavery]

EDIT JUNE 2015:
PLEASE SEE REVISED FILES IN POST BELOW 28 NOV 2014.
B



Here are my experiences of getting NRF24L01+ modules ($1 up on eBay) running on rPi. It is based on Joao Paulo Barraca's pynrf24 python library at https://github.com/jpbarraca/pynrf24. It took some debugging, but now I have a working system that seems stable and adaptable to projects.

How to tweak up JPB's python module to love the Raspberry Pi:

Code: Select all

Tweak Joao Paulo Barraca's BBB/rPi version of nrf24.py:
Get from github at https://github.com/jpbarraca/pynrf24.
Check your version: last line should be line 772:  " return ((250"  etc
We will edit from the bottom upwards, to keep line numbering stable for editing.

JPB's code is admittedly tuned for Beagle Bone Black, with probable validity for rPi.
These are my tweaks that make this library sing on two rPi's here.

1. The calculated timeout of getMaxTimeout (line 770) is (empirically) premature by about 30%.  
Add multiplier " * 2" at end if line 772, to double the timeout.
Crude but adequate. This timeout ought never be hit if the nrf24 chip is functioning,
but all software should guard against sticking in a loop!
But premature timeouts as here seem to get the chip very confused.

2. Delete lines 496 - 501 (the else: irq section).
(I have removed all IRQ function for this version, as rPi would need a rethink anyway.)

3. Line 485. remove third and fourth parameters (IRQ)

4. Add a missing line after line 466.
     465   if what['rx_ready']:
     466       self.ack_payload_length = self.getDynamicPayloadSize()
     467       self.ack_payload_available = True   # needed for ack-payload

5. Add two lines after line 462: 
     460   what = self.whatHappened()
     461
     462   result = what['tx_ok']
     463   if what['tx_fail']:
     464       self.flush_tx();    # dont fill up the tx fifo
     465   # Handle the ack packet
Retry count-out ("tx-fail") in ACK mode does not clear the tx buffer. We need to dump it.

6. Remove line 373 (irq_pin) and line 370 (irq_pin).
In line 365 remove last parameter (irq_pin) in begin().

7. Function print_observe_tx() at line 299+ yields wrong value for PLOS_CNT.
Looking at the code, I'm not sure why, but the result is wrong.
Simple pragmatic solution - put in a replacement that works:
Delete lines 300-305, and replace with one line:
    299   def print_observe_tx(self, value):
    300      print "Observe Tx: %02x  Lost Pkts: %d Retries: %d" % (value, value >> NRF24.PLOS_CNT, value & 15)

8. Delete lines 195-205 (irqWait)

9. Delete line 176 (irq_pin)
Alter line 175 (BBB type pin number) to
     175     self.ce_pin = 17

10. Delete lines 17-24 (BBB configuration)
Replace with these lines:
      18   import RPi.GPIO as GPIO
      19   GPIO.setmode(GPIO.BCM)
      20   GPIO.setwarnings(False)

I used BCM pin 17 as the "CE" for RF24 module, and rPi's ce0 for RF24's "CSN" chip select. 3.3 volts came from rPi.
There are only 3 files, the nrf24.py library and the two send/recv scripts.
The mode used is ack retry with dynamic payload size and ack payload enabled (1-32 bytes transmit payload, and 0-32 bytes ack-payload. My 2 rPis have been chattering happily all overnight, minimum RF power, 2MB/s, across my 6-foot bench, not missing a beat. I can stop the receiver and restart, and everything recovers and resumes happily. I have a working system that can only improve from here.

Now, here is my recv_akpl.py:

Code: Select all

from nrf24 import NRF24
import time

pipes = [[0xe7, 0xe7, 0xe7, 0xe7, 0xe7], [0xc2, 0xc2, 0xc2, 0xc2, 0xc2]]

radio = NRF24()
radio.begin(0, 0, 17)

radio.setRetries(15,15)

radio.setPayloadSize(32)
radio.setChannel(0x60)
radio.setDataRate(NRF24.BR_2MBPS)
radio.setPALevel(NRF24.PA_MIN)

radio.setAutoAck(True)
radio.enableDynamicPayloads()
radio.enableAckPayload()

radio.openWritingPipe(pipes[0])
radio.openReadingPipe(1, pipes[1])

radio.startListening()
radio.stopListening()

radio.printDetails()

radio.startListening()

c=1
while True:
    akpl_buf = [c,1, 2, 3,4,5,6,7,8,9,0,1, 2, 3,4,5,6,7,8]
    pipe = [0]
    # wait for incoming packet from transmitter
    while not radio.available(pipe):
        time.sleep(10000/1000000.0)

    recv_buffer = []
    radio.read(recv_buffer, radio.getDynamicPayloadSize())
    print recv_buffer
    c = c + 1
    if (c&1) == 0:    # queue a return payload every alternate time
        radio.writeAckPayload(1, akpl_buf, len(akpl_buf))

And here is my send_akpl.py:

Code: Select all

from nrf24 import NRF24
import time

pipes = [[0xe7, 0xe7, 0xe7, 0xe7, 0xe7], [0xc2, 0xc2, 0xc2, 0xc2, 0xc2]]

radio = NRF24()
radio.begin(0, 0, 17) #Set ce0/csn and rf24-CE
radio.setRetries(15,15)
radio.setPayloadSize(32)
radio.setChannel(0x60)

radio.setDataRate(NRF24.BR_2MBPS)
radio.setPALevel(NRF24.PA_MIN)
radio.setAutoAck(True)
radio.enableDynamicPayloads()
radio.enableAckPayload()


radio.openWritingPipe(pipes[1])
radio.openReadingPipe(1, pipes[0])

radio.printDetails()

c=1
while True:
    buf = ['H', 'E', 'L', 'O',c]
    c = (c + 1) & 255
    # send a packet to receiver
    radio.write(buf)
    # did it return with a payload?
    if radio.isAckPayloadAvailable():
        pl_buffer=[]
        radio.read(pl_buffer, radio.getDynamicPayloadSize())
        print pl_buffer
    time.sleep(2)

The ack-payload mode suits what I want to use the radio modules for. I had tested blind broadcast (no ACK), simple ACK mode, fixed payload size, and dynamic payload length without ack-payload, and these modes can work OK. I haven't tried old-fashioned half-duplex (swapping transmit/receive functions at each end) - that looks silly considering these chips are now designed for smarter modes.

Also, I haven't tried rPi-arduino by radio yet. (Actually, I did try it early on when the rPi code wasn't yet behaving properly. Guess what? - rPi-arduino wouldn't work properly.)

Maybe IRQ operation should go back one day. The transmit write() function typically takes 2.2 mSec assuming ACK works as intended and no retries are needed, but WAY longer (depending on the delay/count settings you make for retries) if the receiver end is not responding.

[maryus]

Hello !
Can you help me with a code to recive data from raspberry pi to arduino !
I tried to use your code but I could not make it work.

[blavery]

Maryus,
Your question as put is difficult to answer. It's like:

• - I planned to fly up and walk on the moon.
  - I didn't succeed.
  - Where did I go wrong?

What failed? What did you try? What setup are you wiring up? What messages do you see?

Some things you could elaborate on:

• - On the Raspberry Pi end, did the code run, or throw errors?
  - If you have "print_status()" turned on, the page of status should NOT show all 0x00 or 0xFF codes, and it should verify that the NRF24L01+ is indeed a PLUS type, and succeeded in running at 2MHz.
  - Are you trying the same scenario as the examples I used for PI - PI? ie, One "sender" causing each transaction. The receive end being "server", auto-ACK mode with ACK-Payload mode to carry back a pre-loaded package to the sender?
  - How did you connect an arduino end? Recall NRF24's VCC can tolerated no higher than 3.3V, not 5V. Although the logic pins can connect to arduino 5V logic. (The ebay $2 backplate is easy way to get correct 3.3V).
  - Did you track down the ManiacBug equivalent code for arduino and configure it like the recv_akpl.py or send_akpi.py so as to complement the function (send or receive) you are trying to run on your Pi, so the two will talk?

[toxibunny]

bookmarked. thanks!

[luisantunes]

Hi.

First of all thanks for this thread.

I had cloned the Joao Paulo Barraca's repo before and then introduced your modifications since I was not able to put it to work before.

However I'm still not able to do that. I keep getting the following error:

Code: Select all

Traceback (most recent call last):
  File "teste_rx.py", line 7, in <module>
    radio.begin(0, 0, 17)
TypeError: begin() takes exactly 5 arguments (4 given)

Even after changing the radio.begin() and include 4 arguments, I received this error:

Code: Select all

File "recv.py", line 14, in <module>
    radio.begin(1, 0, "P8_23", "P8_24")
  File "/home/pi/pynrf24/examples/nrf24.py", line 353, in begin
    self.spidev.open(major, minor)
IOError: [Errno 2] No such file or directory

Do you have any idea about what's going on here?

Thanks in advance for the help.

Cheers

[blavery]

diag.png (57.3 KiB) Viewed 44945 times

send.png (59.7 KiB) Viewed 44945 times

luisantunes,
I am not in a position currently to get at everything of my work. However, your error message indicates that your python code is still looking at BeagleBone Black rather than changing to Raspberry Pi. So I won't go backwards to what is happening there. I'll move forward to current version I retested a few minutes ago, and it was working.
Go to https://github.com/BLavery/lib_nrf24
and download the ZIP. You want 3 files:

• lib_nfr24.py
  example-nrf24-send-rpi.py
  example-nrf24-recv-rpi.py

The "lib" file is the current derivative of those patches I described in that earlier post. The two "example" files both call that library module.

What is in front of me working right now is TWO Raspberry PIs, each connected to its NRF24 like this:
8-pin connector layout:
GND-------VCC
CE----------CSN
SCK--------MOSI
MISO------IRQ

(radio -> RPi)
"CE" to RPi GPIO#17
"SCK" to SCLK
"MISO" to Miso
"VCC" to +3.3
"CSN" to RPI's "CE0"
"MOSI" to Mosi
IRQ - not used, not connected

One is running "sudo python example.nrf24-send-rpi.py"
Other is running "sudo python example.nrf24-recv-rpi.py"

They should both start off looking like the DIAG.PNG image, showing that NRF24L01+ has been recognised, at 2MBPS. That proves the RPi is talking with its own radio (by SPI). The non-plus NRF will show, at 1MBPS, if things are not OK, and that is the simplest test.

The SEND end (PTX in NRF24 parlance) sends "HELO" repeatedly, in auto-ack mode, with ack-payload. The PTX initiates everything.

The RECV end (PRX mode) awaits packages, displays the "HELO" (in hex) it received,
... and every alternate time prepares a payload to be bundled with the next AUTO-ACK process.
So the reply is seen by the PTX a transaction delayed - it arrives with the ACK sequence of the next transfer. The PRX cannot initiate a transfer, it can only set up a return package to catch a free ride on the next ACK sequence.
Both forward packet payload and return payload are variable size to 32 bytes.

The example files do a transfer every second or two. I do recall some earlier testing where I sped this up to allow the PTX to send pretty much as fast as it could. It all worked fine, but of course the RPI spent time waiting for transactions to complete, because the radio.write() is a blocking call. (I had taken out the IRQ functioning <g>).

This mode (auto-ack, ack-payload, dynamic packet size) seems to me the most useful way to use these radios (needs the PLUS version). All negotiation re package integrity and automatic retries is handled transparently by the radios. No programmed reversal of send and receive roles is needed. (You only have to find a good way to usefully use the ack-payload function for all your reverse traffic.) That is the configuration that both example files set up.

If you have only one RPi, you can possibly share SCLK, MOSI and MISO connection, and assign the second radio to CE1 and another "CE" pin eg GPIO#18. Alter your code to match the 2 pin changes, in the line "radio.begin(0, 17)" (ie CE0 and #17, or CE1 and #18) -- Then run two instances of python code at once. I haven't tried this. (It might have SPI concurrency issues etc) Or you might try to integrate the two radio functions into a single python script as is done in the file "example-nrf24-pair.py" (which is written for virtual-GPIO rather than RPI GPIO). On your own here - sorry I haven't resources just now to do it that way on RPi, although it should be a short job. -- Or you might use one RPi and an Arduino using equivalent sketch and "maniacbug"'s arduino library from which the python library is descended.

(Oh yes, "CE" in NRF24 language has different meaning to "CE" of RPi's SPI connection. Be careful.)

This configuration (incl 2MBPS full speed) I have earlier tested successfully down through two floors of my building - didn't miss a transaction.

Good luck. Let us know if you get it to work.
Brian

[luisantunes]

Thank you for your help!

I managed to be able to initialize the programs and get some (good) feedback:





So I guess the Raspberry part is working.

Then I tried to make it communicate with an Arduino Uno loaded with the GettingStarted example from ManiacBug library.

I got this output from Arduino:



Then I tried to send from Raspberry and receive on Arduino and vice versa and neither of them work.

Any tips?

Once again, thanks mate.

PS: On a side note - I'm using a Raspberry PI B+. I was reading the library code I say a reference saying that something is different. Could that be the reason?

[blavery]

So you want to work the RPI against an arduino?
The Maniacbug library is a good library, but its "examples" as provided do not match the mode auto-ack/ack-payload/dyn-payload that my RPI examples use. They are not an "equivalent sketch". I can see you seem to be using one of the supplied maniacbug examples, or derived from. Your arduino diagnostics shows arduino radio channel 4C instead of RPI channel 60, Dyn/Feature tuned off, 1MBPS speed instead of 2MBPS, etc. In other words, all those configuration lines in your arduino example do not match at all the RPI config. That they won't communicate is obvious. Whatever link you are making between two devices, you need to do all the RF24 setup the same way at both ends. The RF24 is complex. All the corresponding options need to match.

Now, I'm not in a position just now to retest arduino, but I DO HAVE THE CODE that I am pretty sure is what I did use.

RF24_test_TX.ino:

Code: Select all

#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"
#include "elapsedMillis.h"
#include "Arduino.h"
#include<stdio.h>
#include<stddef.h>
#include<limits.h>

RF24 radio1(7,10);
const uint64_t pipe =  0xC2C2C2C2C2LL;


elapsedMillis timeout;

void setup(void)
{

  Serial.begin(57600);
  SerialPrintf_begin();
  printf("\n\rRF24 tx\n\r");
  radio1.begin();

  radio1.setRetries(15,15);
  radio1.setPayloadSize(32);
  radio1.setDataRate(RF24_2MBPS);
  radio1.setPALevel(RF24_PA_MAX);
  radio1.setAutoAck(true);
  radio1.setChannel(0x60);
  radio1.enableDynamicPayloads();
  radio1.enableAckPayload();

  radio1.openReadingPipe(0, pipe);
  radio1.openReadingPipe(1, 0xA0A0A0A0A1LL);

  radio1.openWritingPipe(pipe);
  radio1.powerUp();   // make sure its up & running in time for first pkt
  radio1.printDetails();
  timeout = 0;
}

void Radio1_tx()
{
    static int k=0;

    char bufr[] = "123456789012345678901234567890";
    bufr[0] = k++;
    radio1.write( bufr, 30 );
    //printf("Write exit\n\n");

}


void Radio1_rx()
{
    char buf[33];
    if ( radio1.isAckPayloadAvailable() )
    {
      radio1.read(buf, radio1.ack_payload_length);
      //radio1.read(buf, 2);
      printf("Ack-pl-Rx: %d [%s] \n", radio1.ack_payload_length, buf);

    }


}

void loop(void)
{
    Radio1_rx();
    if (timeout>5000)
        {
        Radio1_tx();
        timeout = 0;
        }


}

and RF24_test_RX.ino:

Code: Select all

#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"
//  #include "elapsedMillis.h"
#include "Arduino.h"
#include<stdio.h>
#include<stddef.h>
#include<limits.h>
//
// Hardware configuration
//

RF24 radio2(7,10);     // pong-back

const uint64_t pipe =  0xC2C2C2C2C2LL;

void setup(void)
{

  Serial.begin(57600);
  SerialPrintf_begin();
  printf("\n\rRF24 rx\n\r");    ///////////////////////
  radio2.begin();
  radio2.setDataRate(RF24_2MBPS);
  radio2.setPALevel(RF24_PA_MAX);
  radio2.setAutoAck(true);
  radio2.setChannel(0x60);
  radio2.enableAckPayload();
  radio2.openReadingPipe(1,pipe);
  radio2.startListening();
  radio2.printDetails();    ///////////////////////
}

struct txpanel {

    char a = 5;
    char c[10];
    char b = 7;

} txp;

char rxbuf[32] ;
char rx_size =0;
bool _rx_available = false;

bool rxAvailable()
{
    // not secure, but adequate?
    bool result = _rx_available;
    _rx_available = false;
    return result;
}

void Radio2()
{
    static char _rxbuf2[32];
    //delay(700);

    if ( radio2.available() )
    {
      bool done = false;
      while (!done)
      {
        rx_size = radio2.getDynamicPayloadSize();
        done = radio2.read( _rxbuf2 ,rx_size);

        if (_rxbuf2[0] != 0)
        // RULE: all incoming radio payloads should have non-zero first char to be a valid info packet.
        // RULE: no assumption re null terminators is made. Binary treatment.
        {
            _rx_available = true;
            memcpy(rxbuf, _rxbuf2, rx_size);
        }
      }

      radio2.writeAckPayload( 1, &txp, sizeof(txpanel) );

    }
}


void loop(void)
{
    Radio2();

   if (rxAvailable())
      printf("Rx <%s>\n",rxbuf);

}

These arduino examples DO initialise the same config pattern as the RPI code. The arduino examples should work arduino - arduino or RPi - arduino.

As I say, I can't test it again just now, sorry. Looking at it, the only thing that might glitch is "printf". I am not sure if printf() was part of maniacbug's library, or something I brought in from elsewhere. If that misbehaves, you need to rewrite that as proper println() equivalents.

Good luck. Again, please let me know if this works.

B

[luisantunes]

Thank you! You are being the best.

Yeah, I noticed the difference of speed between the two configurations but thought that (hopefully) it wasn't enough for them not to communicate. It seems like I still have a long way till understand the RF24 library. And indeed I was using one of the exemples of the Maniacbug library (actually I was finally able to make Arduino and Raspberry communicating with each other, but using some C++ code and libraries and I really need it in Python to integrate with previously done code.

I can't test your code right now but tomorrow I will give it a try and then tell you the results.

[TimK]

Post by luisantunes » Thu Nov 27, 2014 8:13 pm

Even after changing the radio.begin() and include 4 arguments, I received this error:

Code: Select all

File "recv.py", line 14, in <module>
        radio.begin(1, 0, "P8_23", "P8_24")
      File "/home/pi/pynrf24/examples/nrf24.py", line 353, in begin
        self.spidev.open(major, minor)
    IOError: [Errno 2] No such file or directory

I also get the same error.
Did you maybe found the solution? I would be very happy if someone could help me.

[DougieLawson]

What kernel version are you using? Have a look with uname -r.
Have you enabled SPI using the advanced options in sudo raspi-config?

[TimK]

What kernel version are you using? Have a look with uname -r.
Have you enabled SPI using the advanced options in sudo raspi-config?

My kernel version is 3.12.35+. SPI is enabled in my raspi-config (also commented on blacklist).
I am also using spidev from https://pypi.python.org/pypi/spidev.

Thanks for help in advance!

[DougieLawson]

What id are you using? root or pi? or are you prefixing your command with sudo?

If pi without sudo, then has pi been added to the spi group?

sudo useradd -G spi pi

[TimK]

What id are you using? root or pi? or are you prefixing your command with sudo?

If pi without sudo, then has pi been added to the spi group?

sudo useradd -G spi pi

I tried it with (.../nrf.../examples/) sudo python send.py. I will try "sudo useradd -G spi pi" when i get back home since i am in college now.
Thanks for help!

[TimK]

I entered "sudo useradd -G spi pi" , and it says: "useradd: user 'pi' already exists". So I guess it was already done before.
Anything else I should try ??

[joan]

That looks like a type, try usermod rather than useradd.

[jame-james]

Hi I'm having the same issue, don't know if anyone was able to solve it.

After making the modifications of the rf24.py I keep getting this error:

File "recv.py", line 14, in <module>
radio.begin(1, 0, "P8_23", "P8_24")
File "/home/pi/pynrf24/examples/nrf24.py", line 353, in begin
self.spidev.open(major, minor)
IOError: [Errno 2] No such file or directory

[blavery]

You are sure you have SPI working? ie changing the module "blacklist" on older Pi or setting the device tree option in config.txt in RPI2?
(or maybe it's just LATE VERSION OF OS rather than specifically RPI2? In any case, spi enabling is different now.)

The command
ls /dev
should list the spi device as active.

[Bernard275]

In case anyone is still having trouble with this, I had a few hours of not getting this to work before figuring out that where the example script shown has;
radio.begin(1, 0, "P8_23", "P8_24")

it won't work on the raspberry pi which numbers its SPI as SPI0.0 and SPI0.1, and therefore tries to find /dev/spidev1.0 which is a file that doesn't exist

radio.begin(0, 0, "P8_23", "P8_24") works for me, well once I'd seen your comment about CE not having the same meaning on RF24 as RPi - thanks for that and the rest of your work.

[blavery]

I suggest you must be using the early instructions in the very first posting above, on how to adjust jpbarracca's beaglebone version, and haven't fully corrected for RPi pin addresses. Those references are beaglebone pin references!

If instead you look at the github files (my later post 28 Nov 2014 above) you will have then files already fully corrected for the RPI. So try again with those.

[mouraoricardo]

@blavery Good help, with this I was able to put the nrf24l01+ working on python2 raspberry.

Thank you.

[thezanshow]

@BLavery Thank you for putting this together! Definitely saved me some time. I've got your example scripts up and working on my B+ and 2B. After poking around a little I quickly found I can't transmit an integer greater than 2^8. Is there a reason why I'm being limited to sending a 8 bit data packet? How would I go about sending a larger data packet, or a value larger than what can be represented with a single byte?

Or... should I just be limiting myself to sending 0-9 as individual integers that I then later stitch together and use a stop byte to differentiate values...

Thanks!

[blavery]

@thezanshow, it's a while since I fired this up. But the data packet of NRF24 is definitely based on a block of bytes. When you want to transfer whatever data variables or data structure (or string text) you are using, you need to "cast" that some way into a list of bytes, then reconstitute it into your correct variable type or structure at other end. Eg a 16-bit integer would be high byte and low byte parts explicitly separated out for transmission.

[Mantis Toboggan]

Hi blavery, I know you haven't posted in this topic for a while but I am having some issues with this set-up and was wondering if you could point me in the right direction.

I am currently using trying to communicate between two Raspberry Pi 2 boards using the NRF240L (non + version). I am running Arch Linux and have enabled SPI in device tree.

I have downloaded the files:

Code: Select all

lib_nfr24.py
example-nrf24-send-rpi.py
example-nrf24-recv-rpi.py

From your gihub. I have wired them to each other using the instructions you posted on 29/Nov/14.

When I run the send code using

Code: Select all

sudo python2 example-nrf24-send-rpi.py

I receive the following:

Code: Select all

STATUS	 = 0x00 RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=0 TX_FULL=0
RX_ADDR_P0-1	  = 0x0000000000 0x0000000000
RX_ADDR_P2-5	  = 0x00 0x00 0x00 0x00 
TX_ADDR		 = 0x0000000000
RX_PW_P0-6	  = 0x00 0x00 0x00 0x00 0x00 0x00 
EN_AA		 = 0x00 
EN_RXADDR	  = 0x00 
RF_CH		 = 0x00 
RF_SETUP	  = 0x00 
CONFIG		 = 0x00 
DYNPD/FEATURE	  = 0x00 0x00 
Data Rate	 = 1MBPS
Model		 = nRF24L01
CRC Length	 = Disabled
PA Power	 = PA_MIN
Sent: ['H', 'E', 'L', 'O', 1]
Received: Ack only, no payload

Similarly, when I do the receive code:

Code: Select all

STATUS	 = 0x00 RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=0 TX_FULL=0
RX_ADDR_P0-1	  = 0x0000000000 0x0000000000
RX_ADDR_P2-5	  = 0x00 0x00 0x00 0x00 
TX_ADDR		 = 0x0000000000
RX_PW_P0-6	  = 0x00 0x00 0x00 0x00 0x00 0x00 
EN_AA		 = 0x00 
EN_RXADDR	  = 0x00 
RF_CH		 = 0x00 
RF_SETUP	  = 0x00 
CONFIG		 = 0x00 
DYNPD/FEATURE	  = 0x00 0x00 
Data Rate	 = 1MBPS
Model		 = nRF24L01
CRC Length	 = Disabled
PA Power	 = PA_MIN
Received: []
Loaded payload reply: [1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8]
Received: []
(No return payload)

As you can see, it doesn't seem to be working correctly.

I'm not too sure where the issues lays. Can anyone suggest what is the problem?

Thanks.

[blavery]

Hi,
I'm overseas currently, so haven;t got access to much.
From memory, the PLUS version supports several features the the non-plus does not, including optional data frequency (eg 2MHz) and (I think) the run-time variable-length packet sizing, and attaching return data to the auto-ack reply.
I do remember that the code I used did make use of these features, and was specifically set up for non-plus.
Beyond that, I have no answers from here. I haven't used these little boards since then.
Good luck.