The current P2P implementation is very simple and does not implement any prioriatization of any kind: When you send a P2P packet, the radio is taken and the packet is sent without any check for what the radio is currently doing. So if you send a lot of packet in a tight loop you are effectively using the radio all the time and not letting any time for Crazyradio.
On the other side, when communicating with Crazyradio, the Crazyflie is never sending packet by itself but only answering packets from the Crazyradio. So Crazyradio has to poll the Crazyflie by sending packets are regular interval to get data from the Crazyflie. By default this polling loop is very tight, so the Crazyradio is going to use most of the air-time and will not let you much to communicate with P2P packets.
So, as of the current state, both systems will have a hard time working reliably together. One easy thing you can try is to relax the polling time when communicating with Crazyradio, for example by setting waitTime to 0.01 or 0.005 in the communication loop in the lib: https://github.com/bitcraze/crazyflie-l ... er.py#L630
. This will greatly limit the available downstream bandwidth, but it will give more air-time to the P2P packets.
There has been talk about being less 'brutal' with sending P2P packet, and only sending the packet if a communication is not currently in progress with a random back-off wait to avoid mass-collision. I am waiting for a PR on that but I am not sure what the progress it. Together with relaxed Crazyradio polling timing this would greatly help.