Guidelines for Bluetooth and Proprietary Coexistence#

When you start implementing a Bluetooth/Proprietary DMP application, the first thing to consider is if your proprietary protocol is compatible with Bluetooth. Here are some guidelines that you should always consider:

  • Bluetooth is deterministic. The huge advantage of the Bluetooth protocol in a DMP scenario is that it does not send and receive packets at random times, but at predefined time instances – always at the start of a connection interval. This means, among other things, that Bluetooth does not need a background receive, and your proprietary protocol can receive in the background, of course with some interruptions.

  • Bluetooth needs time accuracy. The consequence of predefined time instances is that Bluetooth radio operations need very accurate timing. Radio operation timing needs 500 ppm accuracy. If you delay a Bluetooth packet, it will not be received on the other side. So, in case of collision with a proprietary packet, either the proprietary packet has to be delayed, or one of the packets has to be dropped.

  • Bluetooth connection is active. Once a Bluetooth connection is established, the connection is kept alive by sending and receiving at least an empty packet every connection interval. Consequently, your proprietary protocol needs to be prepared to be interrupted every connection interval. You can, however, set the connection interval to a long period if you do not need low Bluetooth latency. You can also use the peripheral latency parameter to make Bluetooth communication less frequent on the peripheral side.

  • Bluetooth uses short packets. If there is no data to be sent, the Bluetooth connection is kept alive by empty packets. An empty packet takes 80 µs to be sent out on 1M PHY, and 40 µs on 2M PHY. Empty packets sending + inter frame space + empty packet receiving takes 80 + 150 + 80 = 310 µs or 40 + 150 + 40 = 230 µs. This is the usual time needed by Bluetooth in every connection interval. The largest Bluetooth packet has a 257 byte payload which takes 2120 µs to be sent on 1M PHY and 1060 µs on 2M PHY. Along with receiving an empty response packet, this takes 2120 + 150 + 80 = 2350 µs on 1M PHY and 1060 + 150 + 40 = 1250 µs on 2M PHY.

  • Bluetooth uses packet chains. If the data to be sent does not fit into one packet, Bluetooth communication can be extended within a connection interval; that is, you can expect that more than one packet is sent and received in an interval, but this is rare.

  • Bluetooth is robust. If a Bluetooth packet cannot be sent, it will be retransmitted in the next connection interval. If a Bluetooth packet is received with a CRC error, it is always signaled by the other side by not sending a response packet. Again, the packet will be retransmitted in the next connection interval. The only limit is the supervision timeout. If there is no successful transmission within the supervision timeout, then the connection is dropped. In other words, Bluetooth communication can be subdued by higher priority radio tasks for a time interval shorter that the supervision timeout.

  • Summary. When implementing your DMP protocol, you have to take into account that Bluetooth will need the radio every connection interval for a short time (230 µs – 2350 µs). Bluetooth needs accurate timing, so Bluetooth packets cannot be delayed. The Bluetooth packets can interrupt both your packet sending and packet receiving. Therefore, the proprietary protocol should implement acknowledgement and retransmission mechanisms, or a deterministic timing that is interleaved with the Bluetooth communication. Bluetooth communication can be subdued by a higher priority radio task for a time interval shorter than the supervision timeout.