Hi everyone, bumping this thread because I could read some of you were interested in packet loss (@NeverDie and someone else) and my findings could help fix it partially or completely via software.
It's certainly a hardware problem, though I can't figure out if it's due to the components physical positioning, the power supply, or both (and/or more issues like wiring, proper PCB traces, etc).
Also, even the same modules from the same manufacturer, say EByte E01 PA+LNA modules in my case, have shown different performances, so it might be something bound to the variability of the SMD components used as well.
Let's get straight to the point.
I am the developer of rf24tunlink, a radio network bridge which uses primarily nRF24 modules.
During R&D, I found that around 30% of packets from my modules were dropped due to a couple corrupted bytes, which was constant even in close range. That does indicate a hardware problem already, but the distribution of the bit flips is an even stronger indicator.
All flips are in the first bytes!
You might be getting at least one flip in most packets, resulting in ALL of them being dropped automatically because this invalidates the CRC. In this scenario ShockBurst can fail, or you might get duplicates, might not get ACK payloads or simply get a slow link because the same packet can be sent up to 15 times with a wait between each retry.
Not coming here unarmed: how to fix it?
Easy in principle, you:
Disable CRC -> ShockBurst off, no ACK payloads, essentially your module will be RX only.
Implement RS ECC: sacrifice just enough bytes to fix all the corrupted bytes. (in my case, 2/32 was enough!)
That's how I turned a 30% packet loss into a 100% flawless reception, see this result:
There is more to it, as the link gets worse, of course this situation also gets worse. Finding out how many errors are in a packet can help you estimate signal quality and potentially take preventive measures.
Now, if you only care about sending a specific packet, you either receive it or not at all and that's it.
But if you want more like I did, then things get more complicated.
In this case I wanted a full duplex link -> a second pair of nRF24 modules was mandatory
I also wanted to send network data (iperf, ping, ssh, realtime video, audio, telemetry, control, anything really) -> frames needed to be split into radio packets, sent, corrected and stitched back into a frame. That is a HARQ algorithm.
After all of this, I could get a usable network speed of 1.2Mbps (determined via iperf). Used a Pi 4, Pi zero 2 W and 4 nRF24 PA+LNA modules.
You could use this same metric to evaluate your components, some modules could do better and some could do worse.
Would be cool to fix this hardware for all and get closer to that 2Mbps max speed.
Some people declared a speed of 1.7Mbps and I have seen a 1.5Mbps peak during development, so there is definitely room for improvement.
It worked, and I have logos on my next sensor pcb.. 
