So in reviewing this, additional changes are required to support large payloads. The write() function needed to be modified to take into account the max dynamic payload size set in nrf_to_nrf so it knows when to fragment payloads.

Additionally on line 705:

https://github.com/nRF24/RF24Network/pull/244/files#diff-8a8080552c7f675fa680e629d5c5baa2c875d8334cbd57d38b0e44bfc328b751R705-R707

we need to check if encryption is enabled to fragment payloads at the proper sizes. This seems to require adding a new variable to RF24, bool enableEncryption since I am getting errors trying to use this variable without having it defined in RF24. Any idea how to work around adding a variable to RF24 @2bndy5 ?

This is still a bit messy, I'm thinking I can clean it up a whole bunch still by defining variables for MAX_FRAME_SIZE and max_frame_payload_size instead of a mess of #defines.

Can you simply guard the encryption stuff with #ifdef RF52 or something similar?

Can you simply guard the encryption stuff with #ifdef RF52 or something similar?

I tried that here:

#if defined(NRF52_RADIO_LIBRARY)
    uint8_t max_frame_size = NRF_RADIO->PCNF1;
    if(radio.enableEncryption == true){
       max_frame_size -= CCM_IV_SIZE + CCM_COUNTER_SIZE + CCM_MIC_SIZE;
    }
    uint8_t max_frame_payload_size2 = max_frame_size - sizeof(RF24NetworkHeader);
#endif

and get:

RF24Network.cpp:705:14: error: 'class RF24' has no member named 'enableEncryption'

I think because RF24 is included by default, the compiler expects it to have the same variables as nrf_to_nrf

I think we'd need to go by the template typename (radio_t), but I haven't looked into this too deeply.

#if defined(ARDUINO_ARCH_NRF52) || defined(ARDUINO_ARCH_NRF52840) || defined(ARDUINO_ARCH_NRF52833)
// nrf_to_nrf is defined, now compare template radio type
if (radio_t == nrf_to_nrf) {
 // do nRF5x specific stuff
}
#endif

I'm going to setup a dedicated CI workflow for nrf_to_nrf, so we can try to detect build failures before merging without local having to locally build first.

I'll have to build an example from nrf_to_nrf lib...

Memory usage change @ 8d4ecc8

Board,examples/helloworld_rx<br>flash,%,examples/helloworld_rx<br>RAM for global variables,%,examples/helloworld_rx_advanced<br>flash,%,examples/helloworld_rx_advanced<br>RAM for global variables,%,examples/helloworld_tx_advanced<br>flash,%,examples/helloworld_tx_advanced<br>RAM for global variables,%,examples/helloworld_tx<br>flash,%,examples/helloworld_tx<br>RAM for global variables,%,examples/Network_Priority_RX<br>flash,%,examples/Network_Priority_RX<br>RAM for global variables,%,examples/Network_Priority_TX<br>flash,%,examples/Network_Priority_TX<br>RAM for global variables,%
arduino:avr:nano,12,0.04,2,0.1,12,0.04,2,0.1,22,0.07,2,0.1,354,1.15,2,0.1,12,0.04,2,0.1,230,0.75,2,0.1
arduino:samd:mkrzero,4,0.0,8,0.02,4,0.0,8,0.02,8,0.0,8,0.02,8,0.0,8,0.02,4,0.0,8,0.02,8,0.0,8,0.02

ok, I tested this on linux and found no disruption: examples work as expected.

I added copies of RF24Network examples from nrf2nrf library and used them in CI to test build the lib for adafruit feather nrf52840 (using PlatformIO). I'm not proud of the keeping duplicate examples in this lib and nrf2nrf lib, but it was path of least resistance that allowed using the reusable workflow in nRF24/.github repo.

There's a not insignificant increase in compile size on Arduino Nano, So I'm hoping we can do better with the new specialized functions (maybe mark them as inline).

@TMRh20 I noticed a growing list of stale branches in the nrf2nrf repo (most of which have been merged to main). I would suggest allowing github to auto-delete merged branches and delete the 1 branch that was abandoned for a different approach (which was merged to main).

Hmm, adding inline didn't seem to reduce the compile size. I'm not sure if we can avoid this. I suppose the deciding factor would be: Will it still fit on ATTiny85?

The following code still compiles on an ATtiny 84:

Sketch uses 7194 bytes (95%) of program storage space. Maximum is 7552 bytes.
Global variables use 204 bytes (39%) of dynamic memory, leaving 308 bytes for local variables. Maximum is 512 bytes.

#include "RF24.h"
#include "RF24Network.h"
#include "RF24Mesh.h"


/**** Configure the nrf24l01 CE and CS pins ****/
RF24 radio(7, 8);
RF24Network network(radio);
RF24Mesh mesh(radio, network);

/*
 * User Configuration: nodeID - A unique identifier for each radio. Allows addressing
 * to change dynamically with physical changes to the mesh.
 *
 * In this example, configuration takes place below, prior to uploading the sketch to the device
 * A unique value from 1-255 must be configured for each node.
 */
#define nodeID 1


uint32_t displayTimer = 0;

struct payload_t {
  unsigned long ms;
  unsigned long counter;
};

void setup() {

  mesh.setNodeID(nodeID);
  mesh.begin();
}



void loop() {

  mesh.update();

  // Send to the master node every second
  if (millis() - displayTimer >= 1000) {
    displayTimer = millis();

    // Send an 'M' type message containing the current millis()
    if (!mesh.write(&displayTimer, 'M', sizeof(displayTimer))) {
      // If a write fails, check connectivity to the mesh network
      if (!mesh.checkConnection()) {
        //refresh the network address
        if (mesh.renewAddress() == MESH_DEFAULT_ADDRESS) {
          //If address renewal fails, reconfigure the radio and restart the mesh
          //This allows recovery from most if not all radio errors
          mesh.begin();
        }
      }
    }

    while (network.available()) {
      RF24NetworkHeader header;
      payload_t payload;
      network.read(header, &payload, sizeof(payload));
    }
  }
}

I just realized this changes the behavior of the bool ESBNetwork<radio_t>::write(RF24NetworkHeader& header, const void* message, uint16_t len, uint16_t writeDirect) function, which is typically only used in certain situations, but it IS a public function.

For now, users would need to call the standard write bool ESBNetwork<RF24>::write(RF24NetworkHeader& header, const void* message, uint16_t len) function at least once before calling the other write function, in order to set the correct max_payload_size.

I think I'm good with that, since most users probably don't use this function, a comment in the docs is probably good.

Re-thinking it, I'm not good with the previously noted behavior, its like adding a bug for no reason, so I put the max_payload_size calculations in the final bool ESBNetwork<RF24>::write(RF24NetworkHeader& header, const void* message, uint16_t len, uint16_t writeDirect) function

I guess my concerns about compile size are negligible. Especially since NO_MASTER is still an option.

I also agree that behavior is important to remain consistent. Further changes to v2 might be complicated to cherry pick into v1 branch. But I think we can still make it work.

Yeah, for the v1 branch I think it will have to be left up to the user to set the correct MAX_FRAME_SIZE in RF24Network.h

I ended up re-adding the intermediate function, it seemed a better option than recreating the entire write((RF24NetworkHeader& header, const void* message, uint16_t len, uint16_t writeDirect)) function for each radio.

Now the main user write(RF24NetworkHeader& header, const void* message, uint16_t len) function calls write(RF24NetworkHeader& header, const void* message, uint16_t len, uint16_t writeDirect) which sets the max_frame_size then calls main_write()

What a mess of commits lol. Can you tell I've been feeling under the weather lately?

I just went through a week of the flu myself. Still coughing up phlegm...

Ok, we've let it stew a bit here, and I don't see any more changes required. You figure this one is ready to merge?