Robin2:
You say that the Master is receiving the data even though the slave does not know that. I think there must be a risk that the data is invalid.
The data was verified with the crc (and aknowledged) if received, there is no risk of invalid data.
Scenario is a lost Ack as decribed in the datasheet.
Whandall:
The data was verified with the crc (and aknowledged) if received, there is no risk of invalid data.
Scenario is a lost Ack as decribed in the datasheet.
That's useful to know.
I haven't memorized the entire datasheet yet 
However the slave cannot know the data was received without an ack.
...R
Yes, exactly my scenario - data are received OK (CRC check), but ACK is not delivered successfully to the sender. So sender just consider this as not delivered even if it is delivered. Unfortunately this is most likely a limitation (or a feature) in the enhanced shockburst in nrf24l01+. The wireless sensor will retry the transmission 15 times and it will have the same PID. The Master receiver will receive it, validate packet and if validated, it will discard any further packet with the same PID. So example can be during 1st attempt of sending the packet is received and validated on the Master PRX side, then ACK sent back to the sensor PTX, but not received by the sensor PTX. Then sensor PTX will repeat sending 14 times with the same PID and all the 14 packets will be read but discarded by the Master PRX. So on the master side read() function will return payload 1time (14 time the payload is discarded as it is the same PID). Of course it can happen that on 2nd - 15th time the ACK will be received by sensor PTX and further retransmitting will not happen.
Good diagram for the lost ACK scenario is in the datasheet: "7.9.3 - Single transaction with a lost ACK packet"
fanofard:
The wireless sensor will retry the transmission 15 times and it will have the same PID. The Master receiver will receive it, validate packet and if validated, it will discard any further packet with the same PID.
If your slave needs to be sure the data was received the only option is to send it again as a new message. You could include a count value in the message so that the master would know it is a repeat.
It could be that polling by the master (with ackPayload from the slave) would obviate the problem because the acknowledgement is the other way round. But then you need to organize the polling so that when the the slave is awake it receives a poll request - not too difficult, but needs thought.
...R
I suspect a bad combination of timeout and datarate hinders your communication.
Whandall:
I suspect a bad combination of timeout and datarate hinders your communication.
I use 15 retries with the timeout (time waiting between each retry) of 4000us and I always use 250kbps. When I tried 1Mbps, the max range was shorter. I think this should be OK, should not it? I had the issue before when I used 250us as a timeout between each retry - this was not sufficient for 250kbps. But I think having 250kbps with timeout of 4000us should be fine.
As the 4000 µs are the maximum, it can not be the reason for the failure,
if the value really reaches the chip-registers.
I have tested setting of 250us delay together with 250kbps data rate led to fail every time (even in short distance) - that's ok as minimum for an empty ACK packet for this data rate is 500us. So it looks the value is being stored in the chip registers. I will try (just for sure) to set 500 or 750 us and test if the result will be the same asi with 4000us.
If the sensor is able to send the packet, but is unable to get the acknowledge,
why - except for academical reasons - does your sensor need to know that?
If power dissipation is a big factor, sending without acks should be the best choice.
Receiving draws a little more power than sending, so I would try to avoid it.
If you send without ack you can go to sleep much faster also.
Whandall:
If the sensor is able to send the packet, but is unable to get the acknowledge,
why - except for academical reasons - does your sensor need to know that?
It was my initial intention. I wanted to try to resend the measured values couple of times to the receiver in case it failed. But now, after several tests I see this is not good idea. With larger distances the write() function will occasionally return false even if the payload is received by the receiver. So I will simply "fire and forget" it from the wireless sensors. Anyway it works quite reliably (I have some loss, but it is acceptable) and I have monitoring on the server where the values are being stored - so in case there is longer interruption I have an alarm.
If power dissipation is a big factor, sending without acks should be the best choice.
I will keep the ack payload feature on - it can help with reliability but as I mentioned above, I will not rely on what write() function is returning.
BTW: I experimented a bit with the antennas. I made this modification - a dipole antenna: http://www.instructables.com/id/Enhanced-NRF24L01/ It seems to increase the range slightly (without it I got slight packet loss, with this antenna it was without a loss) but it did not solve the ACK is not being received problem I have in the places with larger distances from the receiver.