RF24: one loop takes 30ms :(

I have a remote controlled Dagu Rover 5 ("robotic vehicle"): Playing with Dagu Rover and gripper on Vimeo
The Rover 5 has an ATmega1280 and a nRF24L01 module, the remote control has an ATmega328 and a nRF24L01 module. I have been using it for more then a year without problems. I use the Maniacbug RF24 library. Now recently I connected the 4 encoders to the ATmega1280 and wrote some code to control the speed of the motors using encoder feedback.
Now I tried to integrate my encoder code in to my remote control sketch and ran in to some trouble. I found out that one loop takes a very long 30 milliseconds. This doesn't play well with my encoder code. Leaving out the RF24 radio code the loop takes less then a millisecond.
I have installed this fork of the RF24 library but to no avail. GitHub - gcopeland/RF24: Arduino driver for nRF24L01
Is there any way to let this code run faster?

This is the radio code I use:
Rover 5:

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

unsigned long startTime;
unsigned long endTime;
int time;

typedef struct{
  int X;
  int Y;
  int Z;
  int A;
  int B;
  int C;
  int D;
}
struct1_t;

typedef struct{
  float motors;
  float batRover;
  int distance;
  int bearing;
}
struct2_t;

struct1_t remote; 
struct2_t rover;

RF24 radio(48,49);
const uint64_t pipes[2] = { 
  0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };

void setup()
{
  Serial.begin(115200);
  delay(100);
  radio.begin();
  radio.setDataRate(RF24_250KBPS);
  radio.openWritingPipe(pipes[1]);
  radio.openReadingPipe(1,pipes[0]);
  radio.startListening();
  }
  
void loop(void)
{
  startTime = millis(); 
  
  // radio stuff
  
  radio.stopListening();
  bool ok =radio.write( &rover, sizeof(rover) );
  radio.startListening();
  
  unsigned long started_waiting_at = millis();
  bool timeout = false;
  while ( ! radio.available() && ! timeout )
    if (millis() - started_waiting_at > 100)
      timeout = true;

  if ( timeout )
  {
    Serial.println("Failed, response timed out.");

  }
  else
  {
    radio.read( &remote, sizeof(remote) );

  }
  
  // end of radio stuff
  endTime = millis();
  time = endTime - startTime;
  Serial.print("time = ");
  Serial.println(time);
  }

Remote control:

// Remote
// µController = ATmega328

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

typedef struct{
  int X;
  int Y;
  int Z;
  int A;
  int B;
  int C;
  int D;
}
struct1_t;

typedef struct{
  float motors;
  float batRover;
  int distance;
  int bearing;
}
struct2_t;

struct1_t remote; 
struct2_t rover;

RF24 radio(8,9);
const uint64_t pipes[2] = { 
  0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };


unsigned long startTime;
unsigned long endTime;
int time;

void setup()
{
  Serial.begin(57600);
  radio.begin();
  radio.setDataRate(RF24_250KBPS);
  radio.openWritingPipe(pipes[0]);
  radio.openReadingPipe(1,pipes[1]);
  radio.startListening();
}

void loop(void)
{
  startTime = millis(); 
  
    // radio stuff
  if ( radio.available() )
  {
    bool done = false;
    while (!done)
    {
      done = radio.read( &rover, sizeof(rover) );
    }
    radio.stopListening();
    radio.write(&remote, sizeof(remote) );
    radio.startListening();
  }
  // end of radio stuff
 
  endTime = millis();
  time = endTime - startTime;
  Serial.print("time = ");
  Serial.println(time);
}

Maybe there are lots of errors and the packets are re-sent, if the RF24 doesn't return until sent, then errors could slow things down. I'm starting to use these modules so I'll have a peek in the library code.

Just out of curiosity, have you tried using the radio at a higher speed ( RF24_2MBPS ). And quite possibly a faster SPI speed.

When running the test sketches I have zero packet loss. I'm using modules with amp and preamp, each powered by its own 3V3 regulator and a 100µF electrolytic and a 0.1µF ceramic capacitor on the output of the vreg. I don't think that's the problem...

I just tried using radio.setDataRate(RF24_2MBPS); and that does speed things up. Still not as fast as I want but maybe that's the limit of the hardware (and my lack of coding skills ). Should have tried this a long time ago