This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Interesting error pattern when sending multiple notifications

Other Parts Discussed in Thread: CC2541

I'm running the following test:

  1. initialize BLE in peripheral role, set up GATT database (off chip), make discoverable
  2. wait for connection, set up bonding, exchange keys, turn on encryption
  3. update connection parameters to 7.5 ms interval
  4. wake up every 36 ms
  5. send 20 byte notification on attribute 5 (the packet contains a timestamp and a packet counter)
  6. send 20 byte notification on attribute 6 (the packet contains a timestamp and a packet counter)
  7. send 20 byte notification on attribute 7 (the packet contains a timestamp and a packet counter)
  8. periodically on the master request the packet error status
  9. end the connection after 5 minutes
  10. on the central device, measure latency and count how many packets are received

I am observing the following:

PER stats
   RX Pkts: 44536   RX CRC Fails :  1000   PER:   2.25%
   Events : 40047   Missed Events:  5594
Missed packets:
   0005:   148  (last:  8309)
   0006:   314  (last:  8309)
   0007:   743  (last:  8309)

I would have expected that packets carrying notifications for 5, 6, 7 to have an equal chance of 'crc error'.  But what I am observing is that the 'survival rate' decreases logarithmically!

The packets are sent back-to-back using SPI.  The 'command complete' event for the first notification is received 5.5 ms later, the 'command complete' for the second notification 3 ms after that and the third one 4.8 ms after that.  Between sending the first notification and receiving the last status, there are 14 ms.

How much processing does CC2541 do on a notification packet?  Reading the wiki and the forums, it should be able to send three data packets every 7.5 ms interval.