gettingstarted_call_response.cpp cannont receive packets on Raspberry Pi 2

[evgi9]

Hello,
First thank you for this library.

I have a problem with the examples gettingstarted and gettingstarted_call_response

What I want to do is to send data from an Arduino Uno to a Raspberry Pi 2 for further processing. So I run the examples and set the Uno at Ping Out Role and the RPi at role_pong_back. None of the packets sent from Arduino are received from raspberry.

However, when I do the opposite, setting the role of the RPi as role_ping_out and the Arduino as Pong Back Role, the communication works perfectly, all the packets are received by the Arduino and all the ACK's were returned to the RPi.

Any ideas on how to solve this?

[TMRh20]

Not much software-wise aside from ensuring the radio numbers are set to 0 and 1 for each device.

Beyond that, odd behaviour is usually indicative of a hardware/wiring/external issue. See https:/TMRh20/RF24/wiki/GettingStarted-sketch-failing-to-send:-how-to-diagnose%3F

[evgi9]

The numbers are set to 0 and 1 on each device.
The wiring is not an issue, since the communication RPi -> Arduino works.
The problem is with the software.

I found a small trick that actually enables the Arduino -> RPi communication:

//before main() declare
uint8_t first = 1;

//in the loop right after if ( role == role_pong_back ) {
if (first==1)
{
radio.stopListening();
radio.startListening();
first=0;
}
delay(10);

This way I successfully receive data from the Arduino to my Raspberry Pi 2 but there is a big delay between reading the received data and sending back an ACK, approximately 700-740 msec. This is seen from both the serial window of Arduino, and I confirmed it with an oscilloscope.
I turn on an LED right after
radio.read( &gotByte, 1 );
and turn it off right after
radio.writeAckPayload(pipeNo,&gotByte, 1 );

Any ideas on how to reduce the delay?

[TMRh20]

Thanks: One bug down --> was using dynamicAck setting instead of dynamicPayloads on the RPi call_response sketch. The updated RPi example should resolve the issue (at least partly) I would assume.