Nano IoT as RX and Nano v3 as TX, corrupted RX data

[mrh335]

Describe the bug
A clear and concise description of what the bug is.
When using a Nano v3 to RX or TX to a Nano v3 with version 1.4.1 of the RF24 library, the data is sent and received correctly with acknowledgement.
When switching out the RX Nano v3 for a Nano IoT 33, the RX received is corrupted repeatedly. Switching back to prior setup returns to proper operation.

Rolling back the library to 1.3.5 or earlier allow the Nano IoT 33 to properly RX from the Nano v3 as TX. The issue only comes back when the library is updated to a newer version than 1.3.5. All versions were tested newer than this all with corrupted results.

The Arduinos are both official versions from Arduino.

Results below when using 1.4.1 of library (Expected behavior is that received data matches sent data, but it doesn't)

TX is Nano v3

SimpleTx Starting
Data Sent abcdefghijklmnopqrstuvwxyz  Acknowledge received
Data Sent ABCDEFGHIJKLMNOPQRSTUVWXYZ  Acknowledge received
Data Sent 012345678901234567890123456789  Acknowledge received
Data Sent abcdefghijklmnopqrstuvwxyz  Acknowledge received
Data Sent ABCDEFGHIJKLMNOPQRSTUVWXYZ  Acknowledge received
Data Sent 012345678901234567890123456789  Acknowledge received

RX is Nano IoT 33

Data received qssvwww|}��~���xy{{~���|}�
Data received accfggglmoonoooxy{{~���|}�
Data received 89;;>???<=89;;>???<=89;;>???<=
Data received qssvwww|}��~���xy{{~���|}�
Data received accfggglmoonoooxy{{~���|}�
Data received 89;;>???<=89;;>???<=89;;>???<=

Results below when using 1.3.5 of library (Expected Behavior is correct here)

TX is Nano v3

SimpleTx Starting
Data Sent abcdefghijklmnopqrstuvwxyz  Acknowledge received
Data Sent ABCDEFGHIJKLMNOPQRSTUVWXYZ  Acknowledge received
Data Sent 012345678901234567890123456789  Acknowledge received
Data Sent abcdefghijklmnopqrstuvwxyz  Acknowledge received
Data Sent ABCDEFGHIJKLMNOPQRSTUVWXYZ  Acknowledge received
Data Sent 012345678901234567890123456789  Acknowledge received
Data Sent abcdefghijklmnopqrstuvwxyz  Acknowledge received

RX is Nano IoT 33

Data received abcdefghijklmnopqrstuvwxyz
Data received ABCDEFGHIJKLMNOPQRSTUVWXYZ
Data received 012345678901234567890123456789
Data received abcdefghijklmnopqrstuvwxyz
Data received ABCDEFGHIJKLMNOPQRSTUVWXYZ
Data received 012345678901234567890123456789
Data received abcdefghijklmnopqrstuvwxyz

TX Code

// Special Version.
// Needs matching RX version with   char dataReceived[32] instead of char dataReceived[10]; 

// SimpleTx - the master or the transmitter

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


#define CE_PIN   7
#define CSN_PIN 8

const byte slaveAddress[5] = {'R','x','A','A','A'};


RF24 radio(CE_PIN, CSN_PIN); // Create a Radio

char dataToSend[3][32] = { "abcdefghijklmnopqrstuvwxyz", "ABCDEFGHIJKLMNOPQRSTUVWXYZ" , "012345678901234567890123456789" } ;


unsigned long currentMillis;
unsigned long prevMillis;
unsigned long txIntervalMillis = 1000; // send once per second


void setup() {

    Serial.begin(9600);

    Serial.println("SimpleTx Starting");
// const uint32_t SPI_SPEED = 500000 ; // 500000 Hz
// RF24 radio(CE_PIN, CSN_PIN, SPI_SPEED);  // existing statement modified 
    radio.begin();
        // radio.setPALevel(RF24_PA_MIN);

    radio.setDataRate( RF24_250KBPS );
    radio.setRetries(3,5); // delay, count
    radio.openWritingPipe(slaveAddress);
}

//====================

void loop() {
    currentMillis = millis();
    if (currentMillis - prevMillis >= txIntervalMillis) {
        send();
        prevMillis = millis();
    }
}

//====================

void send() {

    static uint8_t index = 0 ; 

    bool rslt;
    rslt = radio.write( &dataToSend[index ], sizeof(dataToSend[ 0 ] ) );
        // Always use sizeof() as it gives the size as the number of bytes.
        // For example if dataToSend was an int sizeof() would correctly return 2

    Serial.print("Data Sent ");
    Serial.print(dataToSend[ index ] );
    if (rslt) {
        Serial.println("  Acknowledge received");
    }
    else {
        Serial.println("  Tx failed");
    }
    if ( ++index == 3 ) index = 0 ;
}

RX Code

// SimpleRx - the slave or the receiver  32 byte dataReceived version

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

#define CE_PIN   7
#define CSN_PIN 8

const byte thisSlaveAddress[5] = {'R','x','A','A','A'};

RF24 radio(CE_PIN, CSN_PIN);

char dataReceived[32]; // this must match dataToSend in the TX ********************
bool newData = false;

//===========

void setup() {

    Serial.begin(9600);

    Serial.println("SimpleRx Starting");
//     const uint32_t SPI_SPEED = 500000 ; // 500000 Hz
// RF24 radio(CE_PIN, CSN_PIN, SPI_SPEED);  // existing statement modified 
    radio.begin();
    // radio.setPALevel(RF24_PA_MIN);
    radio.setDataRate( RF24_250KBPS );
    radio.openReadingPipe(1, thisSlaveAddress);
    radio.startListening();
}

//=============

void loop() {
    getData();
    showData();
}

//==============

void getData() {
    if ( radio.available() ) {
        radio.read( &dataReceived, sizeof(dataReceived) );
        newData = true;
    }
}

void showData() {
    if (newData == true) {
        Serial.print("Data received ");
        Serial.println(dataReceived);
        newData = false;
    }
}

[2bndy5]

My first guess would be to lower the SPI speed on the Nano IoT 33.

RF24 radio(CE_PIN, CSN_PIN, 4000000);

Have you tried a different data rate?

In the TX code, you should have stopListening() after openWritingPipe() in your setup() function. As far as I know, this has been required since v1.0 (I might be wrong).

I looked into the version diff, and the only thing that sticks out is the modifications to solve #508 (which was related to esp32 on platformIO). The modifications involve moving around the detection of SPI_HAS_TRANSACTIONS macro (which is supposed to be defined by the platform's SPI.h).

[2bndy5]

Ironically, there are also changes to the private member RF24::spi_speed in v1.3.6, so maybe my first guess isn't that far off. However, specifying the SPI speed on Arduino platforms wasn't available (in the constructor) until v1.3.7. Prior to v1.3.7, I think the SPI speed was only configurable (for Arduino platforms) in the RF24_config.h file

[2bndy5]

I did some digging in the arduino/ArduinoCore-samd repo and found this comment

// SPI_HAS_TRANSACTION means SPI has
//   - beginTransaction()
//   - endTransaction()
//   - usingInterrupt()
//   - SPISetting(clock, bitOrder, dataMode)
// #define SPI_HAS_TRANSACTION 1
// Every core implementing arduino API has SPI transaction

So, the SPI_HAS_TRANSACTION macro is defined in the unified Arduino API which is included with the SAMD core when installing it. BTW, the Nano IoT 33 uses a atsamd21g18 as the main CPU; it does not use an ESP32 for its WiFi/BLE component.

Conclusion (concerning the Nano IoT 33 board)

If the RF24_SPI_HAS_TRANSACTIONS macro was not getting properly defined in v1.3.5 or earlier (the real problem with #508), then the call to SPI.begin() was using the default SPI speed of 4000000 Hz. After #508 was resolved (v1.3.6 or later), the default SPI speed was properly set to 10000000 Hz as originally intended (by TMRh20 - not by ManiacBug's earlier initial codebase).

TLDR

My first guess was correct. In v1.3.7 or later, set the SPI speed to something lower than default:

RF24 radio(CE_PIN, CSN_PIN, 4000000); // RF24 lib defaults to 10 MHz

For v1.3.6 and earlier, you can only re-configure the RF24 lib default SPI speed via the RF24_config.h file.

RF24/RF24_config.h

Line 32 in 7dc779c

#define RF24_SPI_SPEED 10000000

In v1.3.5 and earlier, this line used to be

RF24/RF24_config.h

Line 63 in 80ef52b

const uint32_t RF24_SPI_SPEED = 10000000;

PS - As always with SPI speed problems, we recommend you make sure the wire connections aren't loose and not too long.

[mrh335]

Confirmed that adding in this information with version 1.4.1 of the library results in working communication with the Nano IoT 33 and Nano v3 with IoT as the RX or TX.

const uint32_t SPI_SPEED = 500000 ; // 500000 Hz
RF24 radio(CE_PIN, CSN_PIN,SPI_SPEED); // Create a Radio

I am not sure whether this should now be closed or if there is a fix which could be generated to handle this case automatically.

[2bndy5]

I think the problem (which isn't that common) is the RF24 lib's default speed of 10MHz is literally the max speed that the nRF24L01 can support. I don't think its worth reverting back to ManiacBug's original default value 4 MHz (which was mostly selected because of the Arduino platform's default SPI speed - partly to avoid poor wiring). Ultimately, I think this is a wiring issue that can be solved (like you did) only when it arises.

a fix which could be generated to handle this case automatically.

A solution like this isn't very sustainable and would likely lead to having a list of specific boards that get treated specially 👎🏼