nRF24
[Question]: Must ackpayload be the same length as the sent payload?
What would you like to know?
The official ackpayload demo worked. When I changed the ackpayload length(e.g. 8bytes sent and 16bytes ackpayload) ,the radios cannot communicate anymore.
No, ACK payload size is not dependent on incoming payload size.
ACK payloads are dynamically sized. This implies that all payloads are dynamically sized when using ACK payloads.
When I changes the ackpayload length(e.g. 8bytes sent and 16bytes ackpayload) ,the radios cannot communicate anymore.
I suspect you changed more than just the payload size. We cannot help you diagnose a problem if you only tell us what you think caused it.
Also have a look at our docs:
enableAckPayload()writeAckPayload()setRetries()This is important because a short delay between TX attempts will ultimately break use of ACK payloads.
I'm working on drone project,which requires to send essential data back. When running the gettingstarted demo,my modules cannot change role,so I have to use ackpayload. I only added some code to read the sensors and changed the data to transmit,just in the original ackpayload example. Besides,only RF24_PA_MIN could work for me,and an extra power supply did't solve the problem.
I'm not sure how we can help without seeing the code you are using (and it's output if any).
Besides,only RF24_PA_MIN could work for me,and an extra power supply did't solve the problem.
This is confusing. The examples use RF24_PA_MIN as a hack to save on required TX power. If "an extra power supply did't solve the problem", then either Athe power supply's current wasn't consistent/high enough or Byou somehow wired the circuit wrong.
Remember, power ($P$) is defined as $P=I*V$. It is not enough to only ensure that $V$ is around 3.3 volts. PA/LNA modules can require $I$ to be at least 150 mA to transmit (maybe more depending on the radio's model/manufacturer).
This is from https://forum.arduino.cc/t/rf24-not-working-on-esp32-s3/1399922
Is it the same incident (is @xhy2008 also noname-114514 on Arduino forums)?
I just quickly tested the linux examples and they are able to switch between roles. Although the way the linux examples are written, you have to Ctrl+C on 1 node to break the infinite loop on the other end.
If this is specific to the Arduino examples (or even the Arduino-specific lib code), then that may take longer to assess.
@xhy2008 Have you tried an older version of RF24 library? If you installed the latest version, then start re-installing older versions. If you find that switching the role works on an older version, then that would help us figure out if there is a problem in the RF24 library code.
Thankfully we now keep a CHANGELOG to summarize the changes made between each release. Please note, there were some serious changes in v1.5.0 about startListening() and stopListening(), so the examples may be different between v1.5.0 and older versions.
I suspect this issue may just be related to:
d. If ACK packet payload is activated, ACK packets have dynamic payload lengths and the Dynamic Pay- load Length feature should be enabled for pipe 0 on the PTX and PRX. This is to ensure that they receive the ACK packets with payloads. If the payload in ACK is more than 15 byte in 2Mbps mode the ARD must be 500μS or more, and if the payload is more than 5byte in 1Mbps mode the ARD must be 500μS or more.
@xhy2008 You may just need to increase values in radio.setRetries(15,15);
It would be good to have an exact copy of the modified example to reproduce the issue about an inability to change roles.
@2bndy5 I think this is why he is using ACK payloads, the default gettingstarted example is failing to change roles. I would think this is just a power supply issue.
@2bndy5 Is it the same incident (is @xhy2008 also noname-114514 on Arduino forums)? Yes,that's me. You are so careful.😉 I would try reinstalling an old version.
@TMRh20 I don't think it's because the retry time limit,as my rx node received nothing.But I would try that.
@TMRh20 I tried to increase retry delay,'half' of it worked. I need to call write() lots of times to receive an ackpayload. Now I would try an old version.
I'm using esp32-s3 with a RF module produced by Ebyte. Here is my code: TX:
#include "RF24.h"
#define RF_CE 48
#define RF_CSN 47
#define SCK 21
#define RF_MOSI 37
#define RF_MISO 36
const uint8_t WRITEADDRESS[6]={"12345"};
const uint8_t READADDRESS[6]={"45678"};
struct controldata{
uint8_t throttle;//1byte 0-255
int8_t roll;//1byte -127-128
int8_t pitch;//1byte -127-128
uint8_t command;
};//total 4 byte
struct statdata{
float roll;
float pitch;
uint8_t heading;
float V;
//above costs 16byte
};
class RF{
private:
SPIClass spi=SPIClass(FSPI);
public:
RF24 radio;
bool init(){
spi.begin(SCK,RF_MISO,RF_MOSI,RF_CSN);
if (!radio.begin(&spi,RF_CE,RF_CSN)) {
Serial.println("rf init failed");
return false;
}
radio.setDataRate(RF24_250KBPS);
radio.setAddressWidth(5);
radio.setPALevel(RF24_PA_MIN);
radio.setRetries(15,15);
radio.setCRCLength(RF24_CRC_16);
radio.enableDynamicPayloads();
radio.enableAckPayload();
radio.openWritingPipe(WRITEADDRESS);
radio.openReadingPipe(1, READADDRESS);
radio.stopListening();
return true;
}
statdata sendData(controldata data){
while(!radio.write(&data,sizeof(controldata)))
{
Serial.println("send data failed");
delay(5);
}
statdata rec;
if(radio.available())
radio.read(&rec,sizeof(statdata));
else
Serial.println("No ack payload received");
return rec;
}
};
RX:
#include "RF24.h"
#define RF_CE 48
#define RF_CSN 47
#define SCK 21
#define RF_MOSI 20
#define RF_MISO 19
const uint8_t READADDRESS[6]={"12345"};
const uint8_t WRITEADDRESS[6]={"45678"};
struct controldata{
uint8_t throttle;//1byte 0-255
int8_t roll;//1byte -127-128
int8_t pitch;//1byte -127-128
uint8_t command;
};//4 byte
struct statdata{
float roll;
float pitch;
uint8_t heading;
float V;
//above costs 16byte
};
class RF{
private:
SPIClass spi=SPIClass(HSPI);
public:
RF24 radio;
bool init(){
spi.begin(SCK,RF_MISO,RF_MOSI,RF_CSN);
if (!radio.begin(&spi,RF_CE,RF_CSN)) {
Serial.println("rf init failed");
return false;
}
radio.setDataRate(RF24_250KBPS);
radio.setPALevel(RF24_PA_MIN);
radio.setAddressWidth(5);
radio.setRetries(15,15);
radio.setCRCLength(RF24_CRC_16);
radio.enableDynamicPayloads();
radio.enableAckPayload();
radio.openReadingPipe(1,READADDRESS);
radio.openWritingPipe(WRITEADDRESS);
radio.startListening();
return true;
}
controldata recv(statdata data){
radio.writeAckPayload(1, &data, sizeof(statdata));
//Serial.print("Write ack payload ,size:");
//Serial.println(sizeof(statdata));
while(!radio.available())
{
delayMicroseconds(128);
}
controldata ret;
radio.read(&ret,sizeof(controldata));
return ret;
}
};
@xhy2008 I think the main problem here is going to be power supply related. Since it is functioning at a basic level, there is not much we can do from a library standpoint. It works fine on all my devices. Testing with 3v batteries is probably the best option, since they are probably the cleanest source of stable power.
"It would be good to have an exact copy of the modified example to reproduce the issue about an inability to change roles"
is a subfield of cryptography with the goal of creating methods for parties to jointly compute a function over their inputs while keeping those inputs private. Type V
